idnits 2.17.1 draft-ietf-supa-generic-policy-info-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2017) is 2652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '22' is mentioned on line 4196, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-supa-generic-policy-data-model-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Strassner 2 Internet Draft Huawei Technologies 3 Intended status: Standard Track J. Halpern 4 Expires: July 20, 2017 S. van der Meer 5 Ericsson 6 January 18, 2017 8 Generic Policy Information Model for 9 Simplified Use of Policy Abstractions (SUPA) 10 draft-ietf-supa-generic-policy-info-model-02 12 Abstract 14 This document defines an information model for representing 15 policies using a common extensible framework that is independent 16 of language, protocol, repository. It is also independent of the 17 level of abstraction of the content and meaning of a policy. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current 27 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 This Internet-Draft will expire on July 20, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided 50 without warranty as described in the Simplified BSD License. 52 Table of Contents 53 *** Note: this is out of date, will be fixed in next version *** 55 1. Overview ....................................................... 9 56 1.1. Introduction .............................................. 9 57 1.2. Changes Since Version -03 ................................ 11 58 2. Conventions Used in This Document ............................. 11 59 3. Terminology ................................................... 12 60 3.1. Acronyms ................................................. 12 61 3.2. Definitions .............................................. 12 62 3.2.1. Core Terminology .................................... 12 63 3.2.1.1. Information Model .............................. 12 64 3.2.1.2. Data Model ..................................... 13 65 3.2.1.3. Class .......................................... 13 66 3.2.1.3.1. Abstract Class ............................... 13 67 3.2.1.3.2. Concrete Class ............................... 13 68 3.2.1.4. Container ...................................... 13 69 3.2.1.5. PolicyContainer ................................ 13 70 3.2.2. Policy Terminology .................................. 14 71 3.2.2.1. SUPAPolicyObject ............................... 14 72 3.2.2.2. SUPAPolicy ..................................... 14 73 3.2.2.3. SUPAPolicyClause ............................... 14 74 3.2.2.4. SUPAECAPolicyRule .............................. 15 75 3.2.2.5. SUPAMetadata ................................... 15 76 3.2.2.6. SUPAPolicyTarget ............................... 15 77 3.2.2.7. SUPAPolicySource ............................... 15 78 3.2.3. Modeling Terminology ................................ 16 79 3.2.3.1. Inheritance .................................... 16 80 3.2.3.2. Relationship ................................... 16 81 3.2.3.3. Association .................................... 17 82 3.2.3.4. Aggregation .................................... 17 83 3.2.3.5. Composition .................................... 17 84 3.2.3.6. Association Class .............................. 17 85 3.2.3.7. Multiplicity ................................... 18 86 3.2.3.8. Navigability ................................... 18 87 3.3. Symbology ................................................ 18 88 3.3.1. Inheritance ......................................... 18 89 3.3.2. Association ......................................... 19 90 3.3.3. Aggregation ......................................... 19 91 3.3.4. Composition ......................................... 19 92 3.3.5. Association Class ................................... 19 93 3.3.6. Abstract vs. Concrete Classes ....................... 20 94 4. Policy Abstraction Architecture ............................... 21 95 4.1. Motivation ............................................... 22 96 4.2. SUPA Approach ............................................ 23 98 Table of Contents (continued) 100 4.3. SUPA Generic Policy Information Model Overview............ 23 101 4.3.1. SUPAPolicyObject .................................... 25 102 4.3.2. SUPAPolicyStructure ................................. 26 103 4.3.3. SUPAPolicyComponentStructure ........................ 26 104 4.3.4. SUPAPolicyClause .................................... 27 105 4.3.5. SUPAPolicyComponentDecorator ........................ 27 106 4.3.6. SUPAPolicyTarget .................................... 28 107 4.3.7. SUPAPolicySource .................................... 28 108 4.4. The Design of the GPIM ................................... 28 109 4.4.1. Structure of Policies ............................... 29 110 4.4.2. Representing an ECA Policy Rule ..................... 30 111 4.4.3. Creating SUPA Policy Clauses ........................ 33 112 4.4.4. Creating SUPAPolicyClauses .......................... 36 113 4.4.5. SUPAPolicySources ................................... 37 114 4.4.6. SUPAPolicyTargets ................................... 39 115 4.4.7. SUPAPolicyMetadata .................................. 39 116 4.4.7.1. Motivation ..................................... 39 117 4.4.7.2. Design Approach ................................ 40 118 4.4.7.2.1. Policies and Actors ....................... 42 119 4.4.7.2.2. Deployment vs. Execution of Policies ...... 43 120 4.4.7.2.3. Using SUPAMetadata for Policy Deployment 121 and Execution ............................. 43 122 4.4.7.3. Structure of SUPAPolicyMetadata ................ 44 123 4.5. Advanced Features ........................................ 47 124 4.5.1. Policy Grouping ..................................... 47 125 4.5.2. Policy Rule Nesting ................................. 47 126 5. GPIM Model .................................................... 48 127 5.1. Overview ................................................. 48 128 5.2. The Abstract Class "SUPAPolicyObject" .................... 49 129 5.2.1. SUPAPolicyObject Attributes ......................... 50 130 5.2.1.1. Object Identifiers ............................. 50 131 5.2.1.2. The Attribute "supaPolObjIDContent" ............ 51 132 5.2.1.3. The Attribute "supaPolObjIDEncoding" ........... 51 133 5.2.1.4. The Attribute "supaPolicyDescription" .......... 51 134 5.2.1.5. The Attribute "supaPolicyName" ................. 51 135 5.2.2. SUPAPolicy Relationships ............................ 52 136 5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 52 137 5.2.2.2. The Association Class 138 "SUPAHasPolicyMetadataDetail" .................. 52 139 5.3. The Abstract Class "SUPAPolicyStructure" ................. 52 140 5.3.1. SUPAPolicyStructure Attributes ...................... 53 141 5.3.1.1. The Attribute "supaPolAdminStatus" ............. 53 142 5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 53 143 5.3.1.3. The Attribute "supaPolDeployStatus" ............ 54 144 5.3.1.4. The Attribute "supaPolExecFailStrategy" ........ 54 146 Table of Contents (continued) 148 5.3.2. SUPAPolicyStructure Relationships ................... 55 149 5.3.2.1. The Aggregation "SUPAHasPolicySource" .......... 55 150 5.3.2.2. The Association Class 151 "SUPAHasPolicySourceDetail" .................... 55 152 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" . 55 153 5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" ....... 56 154 5.3.2.3. The Aggregation "SUPAHasPolicyTarget" .......... 56 155 5.3.2.4. The Association Class 156 "SUPAHasPolicyTargetDetail" ................... 56 157 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" . 56 158 5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" ....... 56 159 5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" . 57 160 5.3.2.6. The Association Class 161 "SUPAHasPolExecFailTakeActionDetail" ........... 57 162 5.3.2.6.1. The Attribute 163 "supaPolExecFailActionEncoding" ........... 57 164 5.3.2.6.2. The Attribute 165 "supaPolExecFailActionName[1..n]" ......... 58 166 5.3.2.7. The Aggregation "SUPAHasPolicyClause" .......... 58 167 5.3.2.8. The Association Class 168 "SUPAHasPolicyClauseDetail" .................... 58 169 5.4. The Abstract Class "SUPAPolicyComponentStructure" ........ 59 170 5.4.1. SUPAPolicyComponentStructure Attributes ............. 59 171 5.4.2. SUPAPolicyComponentStructure Relationships .......... 59 172 5.5. The Abstract Class "SUPAPolicyClause" .................... 59 173 5.5.1. SUPAPolicyClause Attributes ......................... 60 174 5.5.1.1. The Attribute "supaPolClauseDeployStatus" ...... 60 175 5.5.2. SUPAPolicyClause Relationships ...................... 61 176 5.6. The Concrete Class "SUPAEncodedClause" ................... 61 177 5.6.1. SUPAEncodedClause Attributes ........................ 61 178 5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 61 179 5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 61 180 5.6.1.3. The Attribute "supaEncodedClauseLanguage" ...... 62 181 5.6.1.4. The Attribute "supaEncodedClauseResponse" ...... 62 182 5.6.2. SUPAEncodedClause Relationships ..................... 62 183 5.7. The Abstract Class "SUPAPolicyComponentDecorator" ........ 62 184 5.7.1. The Decorator Pattern ............................... 63 185 5.7.2. SUPAPolicyComponentDecorator Attributes ............. 64 186 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 65 187 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 65 188 5.7.3. SUPAPolicyComponentDecorator Relationships .......... 65 189 5.7.3.1. The Aggregation 190 "SUPAHasDecoratedPolicyComponent" .............. 66 191 5.7.3.2. The Association Class 192 "SUPAHasDecoratedPolicyComponentDetail" ........ 66 193 5.7.3.2.1. The Attribute 194 "supaDecoratedConstraintEncoding" ......... 66 195 5.7.3.2.2. The Attribute 196 "supaDecoratedConstraint[0..n]" ........... 67 198 Table of Contents (continued) 200 5.7.4. Illustration of Constraints in the Decorator Pattern 67 201 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 68 202 5.8.1. SUPAPolicyTerm Attributes ........................... 69 203 5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 69 204 5.8.2. SUPAPolicyTerm Relationships ........................ 69 205 5.9. The Concrete Class "SUPAPolicyVariable" .................. 69 206 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 70 207 5.9.2. SUPAPolicyVariable Attributes ....................... 70 208 5.9.2.1. The Attribute "supaPolVarName" ................. 70 209 5.9.3. SUPAPolicyVariable Relationships .................... 70 210 5.10. The Concrete Class "SUPAPolicyOperator" ................. 70 211 5.10.1. Problems with the RFC3460 Version .................. 71 212 5.10.2. SUPAPolicyOperator Attributes ...................... 71 213 5.10.2.1. The Attribute "supaPolOpType" ................. 71 214 5.10.3. SUPAPolicyOperator Relationships ................... 71 215 5.11. The Concrete Class "SUPAPolicyValue" .................... 72 216 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 72 217 5.11.2. SUPAPolicyValue Attributes ......................... 72 218 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 72 219 5.11.2.2. The Attribute "supaPolValEncoding" ............ 73 220 5.11.3. SUPAPolicyValue Relationships ...................... 73 221 5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 73 222 5.12.1. SUPAGenericDecoratedComponent Attributes ........... 74 223 5.12.1.1. The Attribute 224 "supaVendorDecoratedCompContent[0..n]" ........ 74 225 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 74 226 5.12.2. SUPAGenericDecoratedComponent Relationships ........ 74 227 5.13. The Concrete Class "SUPAPolicyCollection" ............... 75 228 5.13.1. Motivation ......................................... 75 229 5.13.2. Solution ........................................... 75 230 5.13.3. SUPAPolicyCollection Attributes .................... 76 231 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 76 232 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 76 233 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 76 234 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 76 235 5.13.3.5. The Attribute "supaPolCollectionType" ......... 77 236 5.13.4. SUPAPolicyCollection Relationships ................. 78 237 5.14. The Concrete Class "SUPAPolicySource" .................... 78 238 5.14.1. SUPAPolicySource Attributes ........................ 78 239 5.14.2. SUPAPolicySource Relationships ..................... 78 240 5.15. The Concrete Class "SUPAPolicyTarget" ................... 78 241 5.15.1. SUPAPolicyTarget Attributes ........................ 79 242 5.15.2. SUPAPolicyTarget Relationships ..................... 79 244 Table of Contents (continued) 246 5.16. The Abstract Class "SUPAPolicyMetadata" ................. 79 247 5.16.1. SUPAPolicyMetadata Attributes ...................... 80 248 5.16.1.1. The Attribute "supaPolMetadataDescription" .... 80 249 5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 80 250 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 80 251 5.16.1.4. The Attribute "supaPolMetadataName" ........... 81 252 5.16.2. SUPAPolicyMetadata Relationships ................... 81 253 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 81 254 5.16.2.2. The Association Class 255 "SUPAHasPolicyMetadataDetail" ................. 81 256 5.16.2.2.1. The Attribute 257 "supaPolMetadataIsApplicable" ............ 81 258 5.16.2.2.2. The Attribute 259 "supaPolMetadataConstraintEncoding" ...... 82 260 5.16.2.2.3. The Attribute 261 "supaPolMetadataConstraint[0..n]" ........ 82 262 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 82 263 5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 83 264 5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" ...... 83 265 5.17.1.2. The Attribute "supaPolMDValidPeriodStart" .... 83 266 5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 83 267 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 83 268 5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 83 269 5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 83 270 5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" .... 84 271 5.18.2.2. The Association Class 272 "SUPAHasMetadataDecoratorDetail" .............. 84 273 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 84 274 5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 85 275 5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 85 276 5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 85 277 5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 86 278 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 86 279 5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 86 280 5.20.1.1. The Attribute "supaVersionMajor" .............. 87 281 5.20.1.2. The Attribute "supaVersionMinor" .............. 88 282 5.20.1.3. The Attribute "supaVersionPatch" .............. 88 283 5.20.1.4. The Attribute "supaVersionPreRelease" ......... 88 284 5.20.1.5. The Attribute "supaVersionBuildMetadata" ...... 89 285 6. SUPA ECAPolicyRule Information Model .......................... 89 286 6.1. Overview ................................................. 89 287 6.2. Constructing a SUPAECAPolicyRule ......................... 91 288 6.3. Working With SUPAECAPolicyRules .......................... 92 289 6.4. The Abstract Class "SUPAECAPolicyRule" ................... 93 290 6.4.1. SUPAECAPolicyRule Attributes ........................ 95 291 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 95 292 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ........ 95 293 6.4.2. SUPAECAPolicyRule Relationships ..................... 96 295 Table of Contents (continued) 297 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 96 298 6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 96 299 6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 96 300 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 96 301 6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 96 302 6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 97 303 6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 97 304 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 98 305 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 98 306 6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 98 307 6.7. The Abstract Class "SUPABooleanClause" ................... 98 308 6.7.1. SUPABooleanClause Attributes ........................ 99 309 6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 99 310 6.7.2. SUPABooleanClause Relationships ..................... 99 311 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............ 100 312 6.8.1. SUPABooleanClauseAtomic Attributes ................. 100 313 6.8.2. SUPABooleanClauseAtomic Relationships .............. 100 314 6.9. The Concrete Class "SUPABooleanClauseComposite" ......... 100 315 6.9.1. SUPABooleanClauseComposite Attributes .............. 100 316 6.9.1.1. The Attribute "supaBoolClauseBindValue" ....... 101 317 6.9.1.2. The Attribute "supaBoolClauseIsCNF" ........... 101 318 6.9.2. SUPABooleanClauseComposite Relationships ........... 101 319 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ........ 101 320 6.9.3. The Association Class "SUPAHasBooleanClauseDetail" . 101 321 6.9.3.1. SUPAHasBooleanClauseDetail Attributes ......... 101 322 6.10. The Abstract Class "SUPAECAComponent" .................. 102 323 6.10.1. SUPAECAComponent Attributes ....................... 102 324 6.10.1.1. The Attribute supaECACompIsTerm .............. 102 325 6.10.2. SUPAECAComponent Relationships .................... 102 326 6.11. The Concrete Class "SUPAPolicyEvent" ................... 103 327 6.11.1. SUPAPolicyEvent Attributes ........................ 103 328 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 103 329 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 103 330 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 103 331 6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 103 332 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 104 333 6.11.2. SUPAPolicyEvent Relationships ..................... 104 334 6.12. The Concrete Class "SUPAPolicyCondition" ............... 104 335 6.12.1. SUPAPolicyCondition Attributes .................... 105 336 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 105 337 6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 105 338 6.12.2. SUPAPolicyEvent Relationships ..................... 105 339 6.13. The Concrete Class "SUPAPolicyAction" .................. 106 340 6.13.1. SUPAPolicyAction Attributes ....................... 106 341 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 106 342 6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 107 343 6.13.2. SUPAPolicyAction Relationships .................... 107 345 7. Examples ..................................................... 107 346 8. Security Considerations ..................................... 107 347 9. IANA Considerations .......................................... 107 348 10. Contributors ................................................ 108 349 11. Acknowledgments ............................................. 108 350 12. References .................................................. 108 351 12.1. Normative References ................................... 108 352 12.2. Informative References ................................ 108 353 Authors' Addresses ............................................... 109 354 Appendix A. Brief Analyses of Previous Policy Work .............. 110 355 1. Overview 357 This document defines an information model for representing 358 policies using a common extensible framework that is independent 359 of language, protocol, repository, and the level of abstraction of 360 the content and meaning of a policy. This enables a common set of 361 concepts defined in this information model to be mapped into 362 different representations of policy (e.g., procedural, imperative, 363 and declarative). It also enables different data models that use 364 different languages, protocols, and repositories to optimize 365 their usage. The definition of common policy concepts also 366 provides better interoperability by ensuring that each data 367 model can share a set of common concepts, independent of its 368 level of detail or the language, protocol, and/or repository 369 that it is using. It is also independent of the target data 370 model that will be generated. 372 This version of the information model focuses on defining one 373 type of policy rule: the event-condition-action (ECA) policy rule. 374 Accordingly, this document defines two sets of model elements: 376 1. A framework for defining the concept of policy, 377 independent of how policy is represented or used; this is 378 called the SUPA Generic Policy Information Model (GPIM) 379 2. A framework for defining a policy model that uses the 380 event-condition-action (ECA) paradigm; this is called the 381 SUPA ECA Policy Rule Information Model (EPRIM), and extends 382 concepts from the GPIM. 384 The combination of the GPIM and the EPRIM provides an extensible 385 framework for defining policy that uses an event-condition-action 386 representation that is independent of data repository, data 387 definition language, query language, implementation language, and 388 protocol. 390 The Appendices describe how the structure of the GPIM defines a 391 set of generic concepts that enables other types of policies, such 392 as declarative (or "intent-based") policies, to be added later. 394 1.1. Introduction 396 Simplified Use of Policy Abstractions (SUPA) defines a technology- 397 independent neutral information model for creating high-level, 398 possibly network-wide policies as input and producing element 399 configurations (either whole or snippets) as output. SUPA addresses 400 the needs of operators, end-users, and application developers to 401 represent multiple types of ECA policy rules, such as for traffic 402 selection and configuration or security. These ECA policy rules may 403 vary in the level of abstraction to suit the needs of different 404 actors (e.g., end-users vs. administrators) [1], [10]. 406 Different constituencies of users would like to use terminology and 407 concepts that are familiar to each constituency. Rather than require 408 multiple software systems to be used for each constituency, a common 409 information model enables these different concepts and terms to be 410 mapped to elements in the information model. This facilitiates the 411 use of a single software system to generate data models for each 412 language. In the example shown in Figure 1 (which is a simplified 413 Policy Continuum [10]), each constituency uses different concepts 414 and terms (according to their skill sets and roles) to formulate 415 (ECA) policy rules that are useful for their job functions. A 416 unified information model is one way to build a consensual lexicon 417 that enables terms from one language to be mapped to terms of 418 another language. This approach enables the syntax of each language 419 to be modified appropriate to its user while keeping a common set 420 of semantics for all languages. This is shown in Figure 1. 422 +-------------------+ 423 | Information Model | 424 | and one or more +<------------------------+ 425 | Data Models | | 426 +-------------------+ | 427 | 428 +---------------------+ | 429 +---------------+ \| High-level Policies | \+-------------+ | 430 | Business User |----| Without Technical |----| Language #1 +<----+ 431 +---------------+ /| Terminology | /+-------------+ | 432 +---------------------+ | 433 | 434 +---------------------+ | 435 +---------------+ \| Policies That Use | \+-------------+ | 436 | Developer |----| Classes, Attributes,|----| Language #2 +<----+ 437 +---------------+ /| Relationships, ... | /+-------------+ | 438 +---------------------+ | 439 | 440 ... ... ... | 441 | 442 +---------------------+ | 443 +---------------+ \| Low-level Policies | \+-------------+ | 444 | Admin |----| with Technology- |----| Language #n +<----+ 445 +---------------+ /| Specific Terms in a | /+-------------+ 446 | Specific Language | 447 +---------------------+ 449 Figure 1. Different Constituencies Need Different Policies 451 More importantly, an information model defines concepts in a 452 uniform way, enabling formal mapping processes to be developed to 453 translate the information model to a set of data models. This 454 simplifies the process of constructing software to automate the 455 policy management process. It also simplifies the language 456 generation process, though that is beyond the scope of this 457 document. 459 This common framework takes the form of an information model that 460 is divided into one high-level module and one or more number of 461 lower-level modules. A lower-level module extends the higher-level 462 module into a new domain; each lower-level domain module can itself 463 be extended to model more granular domain-specific (but still 464 technology- and vendor-independent) concepts as necessary. 466 Conceptually, a set of model elements (e.g., classes, attributes, 467 constraints, and relationships) are used to define the Generic 468 Policy Information Model (GPIM); this module defines a common set of 469 policy concepts that are independent of the type of policy (e.g., 470 imperative, procedural, declarative, or otherwise). Then, any number 471 of additional modules can be derived from the GPIM; each additional 472 module MUST extend the GPIM to define a new type of policy rule by 473 adding to the GPIM. Each additoinal module MUST NOT alter any of 474 the model elements of the GPIM. The use of extensions preserves the 475 interoperability of this approach; if the base GPIM was modified, 476 then this would adversely compromise interoperability. 478 The SUPA ECA Policy Rule Information Model (EPRIM) extends the 479 GPIM to represent policy rules that use the Event-Condition-Action 480 (ECA) paradigm. 482 1.2. Changes Since Version -01 484 There are several changes in this version of this document 485 compared to the previous versions of this document. They are: 487 1) Clarified figure 7 and figure 17 488 2) Aligned enumerations in IM with those in DM and standardized 489 values in the IM version and their explanations 490 3) Removed supaPolExecStatus and supaPolClauseExecStatus 491 4) Added supaPolClauseDeployStatus attribute 492 5) Rewrote SUPAPolicyComponentStructure definition 493 6) Rewrote SUPAPolicyClause definition 494 7) Synchronized information and data models. 495 8) Deleted the attribute "supaEncodedClauseLang[0..n]" 496 9) Fixed typos 498 2. Conventions Used in This Document 500 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 501 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 502 this document are to be interpreted as described in [RFC2119]. In 503 this document, these words will appear with that interpretation 504 only when in ALL CAPS. Lower case uses of these words are not to 505 be interpreted as carrying [RFC2119] significance. 507 3. Terminology 509 This section defines acronyms, terms, and symbology used in the 510 rest of this document. 512 3.1. Acronyms 514 CLI Command Line Interface 515 CRUD Create, Read, Update, Delete 516 CNF Conjunctive Normal Form 517 DNF Disjunctive Normal Form 518 ECA Event-Condition-Action 519 EPRIM (SUPA) ECA Policy Rule Information Model 520 GPIM (SUPA) Generic Policy Information Model 521 OAM&P Operations, Administration, Management, and Provisioning 522 OID Object IDentifier 523 SUPA Simplified Use of Policy Abstractions 524 TMF TeleManagent Forum (TM Forum) 525 UML Unified Modeling Language 526 URI Uniform Resource Identifier 527 YANG A data definition language for use with NETCONF 528 ZOOM Zero-touch Orchestration, Operations, and Management 529 (a TMF project that also works on information models) 531 3.2. Definitions 533 This section defines the terminology that is used in this document. 535 3.2.1. Core Terminology 537 The following subsections define the terms "information model" and 538 "data model", as well as "container" and "policy container". 540 3.2.1.1. Information Model 542 An information model is a representation of concepts of interest 543 to an environment in a form that is independent of data repository, 544 data definition language, query language, implementation language, 545 and protocol. 547 Note: this definition is more specific than that of [RFC3198], so 548 as to focus on the properties of information models. That definition 549 was: "An abstraction and representation of the entities in a managed 550 environment, their properties, attributes and operations, and the 551 way that they relate to each other. It is independent of any 552 specific repository, software usage, protocol, or platform." 554 3.2.1.2. Data Model 556 A data model is a representation of concepts of interest to an 557 environment in a form that is dependent on data repository, data 558 definition language, query language, implementation language, and/or 559 protocol (typically, but not necessarily, all five). 561 Note: this definition is more specific than that of [RFC3198], so 562 as to focus on the properties of data models that are generated 563 from information models. That definition was: "A mapping of the 564 contents of an information model into a form that is specific to a 565 particular type of data store or repository." 567 3.2.1.3. Class 569 A class is a set of objects that exhibit a common set of 570 characteristics and behavior. 572 3.2.1.3.1. Abstract Class 574 An abstract class is a class that cannot be directly instantiated. 575 It MAY have abstract or concrete subclasses. It is denoted with a 576 capital A (for abstract) near the top-left side of the class. 578 3.2.1.3.2. Concrete Class 580 A concrete class is a class that can be directly instantiated. Note 581 that classes are either abstract or concrete. In addition, once a 582 class has been defined as concrete in the hierarchy, all of its 583 subclasses MUST also be concrete. It is denoted with a capital C 584 (for concrete) near the top-left side of the class. 586 3.2.1.4. Container 588 A container is an object whose instances may contain zero or more 589 additional objects, including container objects. A container 590 provides storage, query, and retrieval of its contained objects 591 in a well-known, organized way. 593 3.2.1.5. PolicyContainer 595 In this document, a PolicyContainer is a special type of container 596 that provides at least the following three functions: 598 1. It uses metadata to define how its content is interpreted 599 2. It separates the content of the policy from the 600 representation of the policy 601 3. It provides a convenient control point for OAM&P operations 603 The combination of these three functions enables a PolicyContainer 604 to define the behavior of how its constituent components will be 605 accessed, queried, stored, retrieved, and how they operate. 607 This document does NOT define a specific data type to implementation 608 a PolicyContainer, as many different types of data types can be 609 used. However, the data type chosen SHOULD NOT allow duplicate 610 members in the PolicyContainer. In addition, order is irrelevant, 611 since priority will override any initial order of the members of 612 this PolicyContainer. 614 3.2.2. Policy Terminology 616 The following terms define different policy concepts used in the 617 SUPA Generic Policy Information Model (GPIM). Note that the 618 prefix "SUPA" is used for all classes and relationships defined 619 in this model to ensure name uniqueness. Similarly, the prefix 620 "supa" is defined for all SUPA class attributes. 622 3.2.2.1. SUPAPolicyObject 624 A SUPAPolicyObject is the root of the GPIM class hierarchy. It is 625 an abstract class that all classes inherit from, except the 626 SUPAPolicyMetadata class and its subclasses. 628 3.2.2.2. SUPAPolicy 630 A SUPAPolicy is, in this version of this document, an ECA policy 631 rule that is a type of PolicyContainer. The PolicyContainer MUST 632 contain an ECA policy rule, SHOULD contain one or more 633 SUPAPolicyMetadata objects, and MAY contain other elements that 634 define the semantics of the policy rule. Policies are generically 635 defined as a means to monitor and control the changing and/or 636 maintaining of the state of one or more managed objects [1]. In 637 this context, "manage" means that one or more of the following six 638 fundamental operations are supported: create, read, write, delete, 639 start, and stop) [16]. 641 3.2.2.3. SUPAPolicyClause 643 A SUPAPolicyClause is an abstract class. Its subclasses define 644 different types of clauses that are used to create the content 645 for different types of SUPAPolicies. 647 For example, the SUPABooleanClause subclass models the content 648 of a SUPAPolicy as a Boolean clause, where each Boolean clause 649 is made up of a set of reusable objects. In contrast, a 650 SUPAEncodedClause encodes the entire clause as a set of 651 attributes. All types of SUPAPolicies MUST use one or more 652 SUPAPolicyClauses to construct a SUPAPolicy. 654 3.2.2.4. SUPAECAPolicyRule 656 An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an 657 abstract class that is a type of PolicyContainer. It represents 658 a policy rule as a three-tuple, consisting of an event, a 659 condition, and an action clause. In an information model, this 660 takes the form of three different aggregations, one for each 661 clause. Each clause MUST be represented by at least one 662 SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain 663 zero or more SUPAPolicySources, zero or more SUPAPolicyTargets, 664 and zero or more SUPAPolicyMetadata objects. Note that for this 665 version of this document, ECA Policy Rules are the **only** 666 types of Policies that are defined. 668 3.2.2.5. SUPAMetadata 670 Metadata is, literally, data about data. SUPAMetadata is an 671 abstract class that contains prescriptive and/or descriptive 672 information about the object(s) to which it is attached. While 673 metadata can be attached to any information model element, this 674 document only considers metadata attached to classes and 675 relationships. 677 When defined in an information model, each instance of the 678 SUPAMetadata class MUST have its own aggregation relationship 679 with the set of objects that it applies to. However, a data model 680 MAY map these definitions to a more efficient form (e.g., 681 flattening the object instances into a single object instance). 683 3.2.2.6. SUPAPolicyTarget 685 SUPAPolicyTarget is an abstract class that defines a set of 686 managed objects that may be affected by the actions of a 687 SUPAPolicyClause. A SUPAPolicyTarget may use one or more 688 mechanisms to identify the set of managed objects that it 689 affects; examples include OIDs and URIs. 691 When defined in an information model, each instance of the 692 SUPAPolicyTarget class MUST have its own aggregation 693 relationship with each SUPAPolicy that uses it. However, a 694 data model MAY map these definitions to a more efficient form 695 (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and 696 SUPAPolicy object instances into a single object instance). 698 3.2.2.7. SUPAPolicySource 700 SUPAPolicySource is an abstract class that defines a set of 701 managed objects that authored this SUPAPolicyClause. This is 702 required for auditability and authorization policies, as well 703 as some forms of deontic and alethic logic. 705 A SUPAPolicySource may use one or more mechanisms to identify the 706 set of managed objects that authored it; examples include OIDs and 707 URIs. Specifically, policy CRUD MUST be subject to authentication 708 and authorization, and MUST be auditable. Note that the mechanisms 709 for doing these three operations are currently not included, and 710 are for further discussion. 712 When defined in an information model, each instance of the 713 SUPAPolicySource class MUST have its own aggregation relationship 714 with each SUPAPolicy that uses it. However, a data model MAY map 715 these definitions to a more efficient form (e.g., flattening the 716 SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances 717 into a single object instance). 719 3.2.3. Modeling Terminology 721 The following terms define different types of relationships used 722 in the information models of the SUPA Generic Policy Information 723 Model (GPIM). 725 3.2.3.1. Inheritance 727 Inheritance makes an entity at a lower level of abstraction (e.g., 728 the subclass) a type of an entity at a higher level of abstraction 729 (e.g., the superclass). Any attributes and relationships that are 730 defined for the superclass are also defined for the subclass. 731 However, a subclass does NOT change the characteristics or behavior 732 of the attributes or relationships of the superclass that it 733 inherits from. Formally, this is called the Liskov Substitution 734 Principle [7]. This principle is one of the key characteristics 735 that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. 737 A subclass MAY add new attributes and relationships that refine 738 the characteristics and/or behavior of it compared to its 739 superclass. A subclass MUST NOT change inherited attributes or 740 relationships. 742 3.2.3.2. Relationship 744 A relationship is a generic term that represents how a first set 745 of entities interact with a second set of entities. A recursive 746 relationship sets the first and second entity to the same entity. 747 There are three basic types of relationships, as defined in the 748 subsections below: associations, aggregations, and compositions. 750 A subclass MUST NOT change the multiplicity (see section 3.2.3.7) 751 of a relationship that it inherits. A subclass MUST NOT change any 752 attributes of a relation that it inherits that is realized using 753 an association class (see section 3.2.3.6). 755 3.2.3.3. Association 757 An association represents a generic dependency between a first 758 and a second set of entities. In an information model, an 759 association MAY be represented as a class. 761 3.2.3.4. Aggregation 763 An aggregation is a stronger type (i.e., more restricted 764 semantically) of association, and represents a whole-part 765 dependency between a first and a second set of entities. Three 766 objects are defined by an aggregation: the first entity, the 767 second entity, and a new third entity that represents the 768 combination of the first and second entities. 770 The entity owning the aggregation is referred to as the 771 "aggregate", and the entity that is aggregated is referred to as 772 the "part". In an information model, an aggregation MAY be 773 represented as a class. 775 3.2.3.5. Composition 777 A composition is a stronger type (i.e., more restricted 778 semantically) of aggregation, and represents a whole-part 779 dependency with two important behaviors. First, an instance of the 780 part is included in at most one instance of the aggregate at a 781 time. Second, any action performed on the composite entity (i.e., 782 the aggregate) is propagated to its constituent part objects. 783 For example, if the composite entity is deleted, then all of its 784 constituent part entities are also deleted. This is not true of 785 aggregations or associations - in both, only the entity being 786 deleted is actually removed, and the other entities are unaffected. 787 In an information model, a composition MAY be represented as 788 a class. 790 3.2.3.6. Association Class 792 A relationship may be implemented as an association class. This is 793 used to define the relationship as having its own set of features. 794 (Note: in this document, all relationships are implemented as 795 association classes for consistency and to simplify implementation.) 796 More specifically, if the relationship is implemented as an 797 association class, then the attributes of the association class, as 798 well as other relationships that the association class participates 799 in, may be used to define the semantics of the relationship. If the 800 relationship is not implemented as an association class, then no 801 additional semantics (beyond those defined by the type of the 802 relationship) are expressed by the relationship. 804 3.2.3.7. Multiplicity 806 A specification of the range of allowable cardinalities that a set 807 of entities may assume. This is always a pair of ranges, such as 808 1 - 1 or 0..n - 2..5. 810 3.2.3.8. Navigability 812 A relationship may restrict one object from accessing the other 813 object. This document defines two choices: 815 1. Each object is navigable by the other, which is indicated 816 by NOT providing any additional symbology, or 817 2. An object A can navigate to object B, but object B cannot 818 navigate to object A. This is indicated by an open-headed 819 arrow pointing to the object that cannot navigate to the 820 other object. An example is shown below: 822 +---------+ 3..4 +---------+ 823 | | 1..2 \| | 824 | Class A |--------------| Class B | 825 | | /| | 826 +---------+ +---------+ 828 The above figure shows a navigability restriction. Class A can 829 navigate to Class B, but Class B cannot navigate to Class A. This is 830 a mandatory association, since none of the multiplicities contain a 831 '0'. This association reads as follows: 833 Class A depends on 3 to 4 instances of Class B, and 834 Class B depends on 1 to 2 instances of Class A. 836 3.3. Symbology 838 The following symbology is used in this document. 840 3.3.1. Inheritance 842 Inheritance: a subclass inherits the attributes and relationships 843 of its superclass, as shown below: 845 +------------+ 846 | Superclass | 847 +------+-----+ 848 / \ 849 I 850 I 851 I 852 +------+-----+ 853 | Subclass | 854 +------------+ 856 3.3.2. Association 858 Association: Class B depends on Class A, as shown below: 860 +---------+ +---------+ 861 +---------+ +---------+ | | \| | 862 | Class A |------| Class B | | Class A |------| Class B | 863 +---------+ +---------+ | | /| | 864 +---------+ +---------+ 866 association with no association with 867 navigability restrictions navigability restrictions 869 3.3.3. Aggregation 871 Aggregation: Class B is the part, Class A is the aggregate, 872 as shown below: 874 +---------+ +---------+ +---------+ 875 | |/ \ +---------+ | |/ \ \| | 876 | Class A | A ---| Class B | | Class A | A ------| Class B | 877 | |\ / +---------+ | |\ / /| | 878 +---------+ +---------+ +---------+ 880 aggregation with no aggregation with 881 navigability restrictions navigability restrictions 883 3.3.4. Composition 885 Composition: Class B is the part, Class A is the composite, 886 as shown below: 888 +---------+ +---------+ +---------+ 889 | |/ \ +---------+ | |/ \ \| | 890 | Class A | C ---| Class B | | Class A | C ------| Class B | 891 | |\ / +---------+ | |\ / /| | 892 +---------+ +---------+ +---------+ 894 composition with no composition with 895 navigability restrictions navigability restrictions 897 3.3.5. Association Class 899 Association Class: Class C is the association class implementing 900 the relationship D between classes A and B 901 +---------+ +---------+ 902 | Class A |----+-----| Class B | 903 +---------+ ^ +---------+ 904 | 905 | 906 +----------+----------+ 907 | Association Class C | 908 +---------------------+ 910 3.3.6. Abstract vs. Concrete Classes 912 In UML, abstract classes are denoted with their name in italics. 913 For this draft, a capital 'A' will be placed at either the top 914 left or right corner of the class to signify that the class is 915 abstract. Similarly, a captial 'C' will be placed in the same 916 location to represent a concrete class. This is shown below. 918 A C 919 +---------+ +---------+ 920 | Class A | | Class B | 921 +---------+ +---------+ 923 An Abstract Class A Concrete Class 925 4. Policy Abstraction Architecture 927 This section describes the motivation for the policy abstractions 928 that are used in SUPA. The following abstractions are provided: 930 o The GPIM defines a technology-neutral information model that 931 can express the concept of Policy. 932 o All classes, except for SUPAPolicyMetadata, inherit from 933 SUPAPolicyObject, or one of its subclasses. 934 o SUPAPolicyObject and SUPAPolicyMetadata are designed to 935 inherit from classes in another model; the GPIM does not 936 define an "all-encompassing" model. 937 o This version of this document restricts the expression of 938 Policy to a set of event-condition-action clauses. 939 o Each clause is defined as a Boolean expression, and MAY 940 also be defined as a reusable object. 941 o Clauses may be combined to form more complex Boolean 942 expressions. 943 o The purpose of the GPIM is to enable different policies that 944 have fundamentally different representations to share common 945 model elements. Policy statements, which are implemented as 946 instances of the SUPAPolicyClause class, separates the content 947 of a Policy from its representation. This is supported by: 948 o All policy rules (of which SUPAECAPolicyRule is the 949 first example of a concrete class) are derived from 950 the SUPAPolicyStructure class. 951 o All objects that are components of policy rules are 952 derived from the SUPAPolicyComponentStructure class. 953 o A SUPAPolicy MUST contain at least one SUPAPolicyClause. 954 o A SUPAPolicy MAY specify one or more SUPAPolicyTarget, 955 SUPAPolicySource, and SUPAPolicyMetadata objects to 956 augment the semantics of the SUPAPolicy 957 o A SUPAPolicyClause has two subclasses: 958 o A SUPABooleanClause, which is used to build 959 SUPAECAPolicyRules from reusable objects. 960 o A SUPAEncodedClause, which is used for using 961 attributes instead of objects to construct a 962 SUPAECAPolicyRule. 963 o A SUPAECAPolicyRule defines the set of events and conditions 964 that are responsible for executing its actions; it MUST have 965 at least one event clause, at least one condition clause, and 966 at least one action clause. 967 o The action(s) of a SUPAECAPolicyRule are ONLY executed 968 if both the event and condition clauses evaluate to TRUE 969 o A SUPAPolicyAction MAY invoke another SUPAECAPolicyRule 970 (see section 6.13). 971 o SUPAMetadata MAY be defined for any SUPAPolicyObject class. 972 o SUPAMetadata MAY be prescriptive and/or descriptive in nature. 974 4.1. Motivation 976 The power of policy management is its applicability to many 977 different types of systems. There are many different actors that 978 can use a policy management system, including end-users, operators, 979 application developers, and administrators. Each of these 980 constituencies have different concepts and skills, and use 981 different terminology. For example, an operator may want to express 982 an operational rule that states that only Platinum and Gold users 983 can use streaming multimedia applications. As a second example, a 984 network administrator may want to define a more concrete policy 985 rule that looks at the number of dropped packets and, if that 986 number exceeds a programmable threshold, changes the queuing and 987 dropping algorithms used. 989 SUPA may be used to define other types of policies, such as for 990 systems and operations management; an example is: "All routers and 991 switches must have password login disabled". See section 3 of [8] 992 for additional declarative and ECA policy examples. 994 All of the above examples are commonly referred to as "policy 995 rules", but they take very different forms, since they are at very 996 different levels of abstraction and typically authored by 997 different actors. The first was very abstract, and did not contain 998 any technology-specific terms, while the second was more concrete, 999 and likely used technical terms of a general (e.g., IP address 1000 range, port numbers) as well as a vendor-specific nature (e.g., 1001 specific queuing, dropping, and/or scheduling algorithms 1002 implemented in a particular device). The third restricted the type 1003 of login that was permissible for certain types of devices in the 1004 environment. 1006 Note that the first two policy rules could directly affect each 1007 other. For example, Gold and Platinum users might need different 1008 device configurations to give the proper QoS markings to their 1009 streaming multimedia traffic. This is very difficult to do if a 1010 common policy model does not exist, especially if the two policies 1011 are authored by different actors that use different terminology 1012 and have different skill sets. More importantly, the users of 1013 these two policies likely have different job responsibilities. 1014 They may have no idea of the concepts used in each policy. Yet, 1015 their policies need to interact in order for the business to 1016 provide the desired service. This again underscores the need for 1017 a common policy framework. 1019 Certain types of policy rules (e.g., ECA) may express actions, or 1020 other types of operations, that contradict each other. SUPA 1021 provides a rich object model that can be used to support language 1022 definitions that can find and resolve such problems. 1024 4.2. SUPA Approach 1026 The purpose of the SUPA Generic Policy Information Model (GPIM) is 1027 to define a common framework for expressing policies at different 1028 levels of abstraction. SUPA uses the GPIM as a common vocabulary 1029 for representing policy concepts that are independent of language, 1030 protocol, repository, and level of abstraction. This enables 1031 different actors to author and use policies at different levels of 1032 abstraction. This forms a policy continuum [1] [2], where more 1033 abstract policies can be translated into more concrete policies, 1034 and vice-versa. 1036 Most systems define the notion of a policy as a single entity. 1037 This assumes that all users of policy have the same terminology, 1038 and use policy at the same level of abstraction. This is rarely, 1039 if ever, true in modern systems. The policy continuum defines a 1040 set of views (much like RM-ODP's viewpoints [9]) that are each 1041 optimized for a user playing a specific role. SUPA defines the 1042 GPIM as a standard vocabulary and set of concepts that enable 1043 different actors to use different formulations of policy. This 1044 corresponds to the different levels in the policy continuum, and 1045 as such, can make use of previous experience in this area. 1047 It may be necessary to translate a Policy from a general to a more 1048 specific form (while keeping the abstraction level the same). For 1049 example, the declarative policy "Every network attached to a VM 1050 must be a private network owned by someone in the same group as 1051 the owner of the VM" may be translated to more formal form (e.g., 1052 Datalog (as in OpenStack Congress). It may also be necessary to 1053 translate a Policy to a different level of abstraction. For 1054 example, the previous Policy may need to be translated to a form 1055 that network devices can process directly. This requires a common 1056 framework for expressing policies that is independent of the level 1057 of abstraction that a Policy uses. 1059 4.3. SUPA Generic Policy Information Model Overview 1061 Figure 2 illustrates the approach for representing policy rules 1062 in SUPA. The top two layers are defined in this document; the 1063 bottom layer (Data Models) are defined in separate documents. 1064 Conceptually, the GPIM defines a set of objects that define the 1065 key elements of a Policy independent of how it is represented or 1066 its content. As will be shown, there is a significant difference 1067 between SUPAECAPolicyRules (see Section 6) and other types of 1068 policies (see Section 7). In principle, other types of SUPAPolicies 1069 could be defined, but the current charter is restricted to using 1070 only event-condition-action SUPAPolicies as exemplars. 1072 Note: the GPIM MAY be used without the EPRIM. However, in order to 1073 use the EPRIM, the GPIM MUST also be used. 1075 +----------------------------------------------+ 1076 | SUPA Generic Policy Information Model (GPIM) | 1077 +----------------------+-----------------------+ 1078 / \ 1079 | 1080 | 1081 +-----------------+--------------+ 1082 | | 1083 | | 1084 +-----------+---------------+ +-------------+-------------+ 1085 | SUPAECAPolicyRule | | Other Policy Models that | 1086 | Information Model (EPRIM) | | are Derived from the GPIM | 1087 +-----------+---------------+ +-------------+-------------+ 1088 / \ / \ 1089 | | 1090 | | 1091 +-----------+-----------+ +-----------+------------+ 1092 | ECAPolicyRule | | Other Types of | 1093 | Data Model | | Data Models | 1094 +-----------------------+ +------------------------+ 1096 Figure 2. Overview of SUPA Policy Rule Abstractions 1098 This draft defines the GPIM and EPRIM. This draft further assumes 1099 that the SUPA Information Model is made up of either the GPIM or the 1100 combination of the GPIM and the EPRIM. Extensions to both the GPIM 1101 and the EPRIM can be made as long as these extensions do not 1102 conflict with the content and structure defined in the GPIM and 1103 EPRIM. If the GPIM and EPRIM are part of another information model, 1104 then they should collectively still define a single information 1105 model. The GPIM defines the following concepts: 1107 o A class defining the top of the GPIM class hierarchy, called 1108 SUPAPolicyObject 1109 o Four subclasses of SUPAPolicyObject, representing: 1110 o the top of the Policy hierarchy, called 1111 SUPAPolicyStructure 1112 o the top of the Policy component hierarchy, called 1113 SUPAPolicyComponentStructure 1114 o PolicySource 1115 o PolicyTarget 1117 The SUPAPolicyStructure class is the superclass for all types of 1118 Policies (e.g., imperative, declarative, and others). This 1119 document is currently limited to imperative (e.g., ECA) policies. 1120 However, care has been taken to ensure that the attributes and 1121 relationships of the SUPAPolicyStructure class are extensible, 1122 and can be used for more types of policies than just ECA policies. 1124 This yields the following high-level structure: 1126 A 1127 +------------------+ 1128 | SUPAPolicyObject | 1129 +--------+---------+ 1130 / \ 1131 I 1132 I 1133 +----------------+--------------------+ 1134 I I I 1135 A I I A I 1136 +--------+------------+ I +------------+-----------------+ 1137 | SUPAPolicyStructure | I | SUPAPolicyComponentStructure | 1138 +----+----------------+ I +------------+-----------------+ 1139 / \ I / \ 1140 I +--------+----+ I 1141 I I I I 1142 I C I I I 1143 I +-------+----------+ I I 1144 I | SUPAPolicySource | I I 1145 I +------------------+ I I 1146 I I I 1147 I +-------------+ I 1148 I I +-----+-------+ 1149 I C I I I 1150 I +-------+----------+ A I I 1151 I | SUPAPolicyTarget | +--------+---------+ I 1152 I +------------------+ | SUPAPolicyClause | I 1153 A I +------------------+ I 1154 +-----+------------+ I 1155 | SUPAECAPolicyRule| A I 1156 +------------------+ +--------------------+---------+ 1157 | SUPAPolicyComponentDecorator | 1158 +------------------------------+ 1160 Figure 3. Functional View of the Top-Level GPIM 1162 Note that all classes except the SUPAPolicySource and the 1163 SUPAPolicyTarget classes are defined as abstract. This provides 1164 more freedom for the data modeler in implementing the data model. 1165 For example, if the data model uses an object-oriented language, 1166 such as Java, then the above structure enables all of the abstract 1167 classes to be collapsed into a single concrete class. If this is 1168 done, attributes as well as relationships are inherited. 1170 4.3.1. SUPAPolicyObject 1172 A SUPAPolicyObject serves as a single root of the SUPA system 1173 (i.e., all other classes in the model are subclasses of the 1174 SUPAPolicyObject class) except for the Metadata objects, which are 1175 in a separate class hierarchy. This simplifies code generation and 1176 reusability. It also enables SUPAPolicyMetadata objects to be 1177 attached to any appropriate subclass of SUPAPolicyObject. 1179 4.3.2. SUPAPolicyStructure 1181 SUPAPolicyStructure is an abstract superclass that is the base 1182 class for defining different types of policies (however, in this 1183 version of this document, only ECA policy rules are modeled). It 1184 serves as a convenient aggregation point to define atomic (i.e., 1185 individual policies that can be used independently) and composite 1186 (i.e., hierarchies of policies) SUPAPolicies; it also enables 1187 PolicySources and/or PolicyTargets to be associated with a given 1188 set of Policies. 1190 SUPAPolicies are defined as either a stand-alone PolicyContainer 1191 or a hierarchy of PolicyContainers. A PolicyContainer specifies 1192 the structure, content, and optionally, source, target, and 1193 metadata information for a SUPAPolicy. This is implemented by the 1194 subclasses of SUPAPolicyStructure. For example, the composite 1195 pattern is used to create two subclasses of the SUPAECAPolicyRule 1196 class; SUPAECAPolicyRuleAtomic is used for stand-alone policies, 1197 and SUPAECAPolicyRuleComposite is used to build hierarchies of 1198 policies. 1200 This document defines a SUPAPolicy as an ECA Policy Rule, though 1201 the GPIM enables other types of policies to be defined and used 1202 with an ECA policy rule. The GPIM model is used in [2] and [5], 1203 along with extensions that allow [2] and [5] to define multiple 1204 types of policies that are derived from the GPIM. They also allow 1205 different combinations of different types of policy rules to be 1206 used with each other. Most previous work cannot define different 1207 types of policy rules; please see Appendix A for a comparison to 1208 previous work. 1210 4.3.3. SUPAPolicyComponentStructure 1212 SUPAPolicyComponentStructure is an abstract superclass that is the 1213 base class for defining components of different types of policies. 1214 SUPAPolicyStructure subclasses define the structure of a policy, 1215 while SUPAPolicyComponentStructure subclasses define the content 1216 that is contained in the structure of a policy. For example, a 1217 SUPAECAPolicyRule is an imperative policy rule, and defines its 1218 structure; its event, condition, and action clauses are populated 1219 by SUPAPolicyComponentStructure subclasses. The strength of this 1220 design is that different types of policies (e.g., imperative and 1221 declarative policies) can be represented using a common set of 1222 policy components. 1224 Please see Appendix for a comparison to previous work. 1226 4.3.4. SUPAPolicyClause 1228 All policies derived from the GPIM are made up of one or more 1229 SUPAPolicyClauses, which define the content of the Policy. 1230 This enables a Policy of one type (e.g., ECA) to invoke Policies 1231 of the same or different types. SUPAPolicyClause is an abstract 1232 class, and serves as a convenient aggregation point for assembling 1233 other objects that make up a SUPAPolicyClause. 1235 The GPIM defines a single concrete subclass of SUPAPolicyClause, 1236 called SUPAEncodedClause. This is a generic clause, and can be 1237 used by any type of Policy in a stand-alone fashion. It can also 1238 be used in conjunction with other SUPAPolicyClauses. The EPRIM 1239 also defines a subclass of SUPAPolicyClause; see section 6.7). 1241 The structure of the GPIM is meant to provide an extensible 1242 framework for defining different types of policies. This is 1243 demonstrated by the EPRIM (see section 6) and the LSIM (see the 1244 Appendices) that each define new subclasses of SUPAPolicyClause 1245 (i.e., SUPABooleanClause and SUPALogicClause, respectively) 1246 without defining new classes that have no GPIM superclass. 1248 A SUPAPolicyClause is defined as an object. Therefore, clauses and 1249 sets of clauses are objects, which promotes reusability. 1251 4.3.5. SUPAPolicyComponentDecorator 1253 One of the problems in building a policy model is the tendency to 1254 have a multitude of classes, and hence object instances, to 1255 represent different combinations of policy events, conditions, and 1256 actions. This can lead to class and/or relationship explosion. 1257 Please see Appendix A for a comparison to previous work. 1259 SUPAPolicyClauses are constructed using the Decorator Pattern 1260 [11]. This is a design pattern that enables behavior to be 1261 selectively added to an individual object, either statically or 1262 dynamically, without affecting the behavior of other objects from 1263 the same class. The decorator pattern uses composition, instead of 1264 inheritance, to avoid class and relationship explosion. The 1265 decorator pattern also enable new objects to be composed from 1266 parts or all of existing objects without affecting the existing 1267 objects. 1269 This enables the resulting SUPAPolicyClause to be constructed 1270 completely from objects in the SUPA information model. This 1271 facilitates the construction of policies at runtime by a machine. 1272 This is also true of [2] and [5]; however, this is NOT true of 1273 most other models. Please see Appendix A for a comparison to 1274 previous work. 1276 SUPAPolicyComponentDecorator defines four types of objects that 1277 can be used to form a SUPAPolicyClause. Each object may be used 1278 with all other objects, if desired. The first three are defined 1279 in the GPIM, with the last defined in the EPRIM. The objects are: 1281 o SUPAPolicyTerm, which enables a clause to be defined in a 1282 canonical {variable, operator, value} form 1283 o SUPAGenericDecoratedComponent, which enabled a custom object 1284 to be defined and then used in a SUPAPolicyClause 1285 o SUPAPolicyCollection, which enables a collection of objects 1286 to be gathered together and associated with all or a portion 1287 of a SUPAPolicyClause 1288 o SUPAECAComponent, which defines Events, Conditions, and 1289 Actions as reusable objects 1291 This approach facilitates the machine-driven construction of 1292 policies. Note that this is completely optional; policies do not 1293 have to use these constructs. 1295 4.3.6. SUPAPolicyTarget 1297 A SUPAPolicyTarget is a set of managed entities that a SUPAPolicy 1298 is applied to. A managed entity can only be designated a 1299 SUPAPolicyTarget if it can process actions from a SUPAPolicy. 1301 A managed object may not be in a state that enables management 1302 operations to be performed on it. Furthermore, the policy-based 1303 management system SHOULD ensure that the management entity 1304 performing the management operations has the proper permissions to 1305 perform the management operations. The design of the 1306 SUPAPolicyTarget addresses both of these criteria. 1308 4.3.7. SUPAPolicySource 1310 A SUPAPolicySource is a set of managed entities that authored, or 1311 are otherwise responsible for, this SUPAPolicy. Note that a 1312 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 1313 primary use is for auditability and the implementation of deontic 1314 and/or alethic logic. 1316 4.4. The Design of the GPIM 1318 This section describes the overall design of the GPIM. 1320 The GPIM defines a policy as a type of PolicyContainer. For this 1321 version, only ECA Policy Rules will be described. However, it 1322 should be noted that the mechanism described is applicable to 1323 other types of policies (e.g., declarative) as well. 1325 4.4.1. Structure of Policies 1327 Recall that a PolicyContainer was defined as a special type of 1328 container that provides at least the following three functions: 1330 1. It uses metadata to define how its content is described 1331 and/or prescribed 1332 2. It separates the content of the policy from the 1333 representation of the policy 1334 3. It provides a convenient control point for OAMP operations. 1336 The first requirement is provided by the ability for any subclass 1337 of Policy (the root of the information model) to aggregate one or 1338 more concrete instances of a SUPAPolicyMetadata class. This is 1339 explained in detail in section 5.2.2. 1341 The second requirement is met by representing an ECA Policy as 1342 having two parts: (1) a rule part and (2) components that make up 1343 the rule. Since functional and declarative policies are not, 1344 strictly speaking, "rules", the former is named PolicyStructure, 1345 while the latter is named PolicyComponentStructure. 1347 The third requirement is met by the concrete subclasses of 1348 PolicyStructure. Since they are PolicyContainers, they are made 1349 up of the SUPAECAPolicyRule, its commponents, and any metadata 1350 that applies to the PolicyContainer, the SUPAECAPolicyRule, and.or 1351 any components of the SUPAECAPolicyRule. This provides optional 1352 low-level control over any part of the SUPAECAPolicyRule. 1354 The above requirements result in the design shown in Figure 4. 1356 A SUPAHasPolicyMetadata A 1357 +------------------+/ \ \+--------------------+ 1358 | SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata | 1359 +---------+--------+\ / /+--------------------+ 1360 / \ 0..n 0..n 1361 I 1362 I 1363 +------+------------------------------------+ 1364 I I 1365 A I A I 1366 +--------+------------+ +------------------+-----------+ 1367 | SUPAPolicyStructure | | SUPAPolicyComponentStructure | 1368 +--------+------------+ +-------------+----------------+ 1369 / \ / \ 1370 I I 1371 I I 1372 (subclasses representing (subclasses representing 1373 different types of policies) different policy components) 1375 Figure 4. Structure of a Policy 1377 Note that aggregation in Figure 4 (named SUPAHasPolicyMetadata) 1378 is realized as an association class, in order to manage which set 1379 of Metadata can be aggregated by which SUPAPolicyObject. The 1380 combination of these three functions enables a PolicyContainer 1381 to define the behavior of how its constituent components will be 1382 accessed, queried, stored, retrieved, and how they operate. 1384 It is often necessary to construct groups of policies. The GPIM 1385 follows [2] and [5], and uses the composite pattern [11] to 1386 implement this functionality, as shown in Figure 5 below. There 1387 are a number of advantages to using the composite pattern over a 1388 simple relationship, as detailed in [11]. 1390 Figure 5 shows that SUPAPolicyStructure has a single subclass, 1391 called SUPAECAPolicyRule. Note, however, that other types of 1392 policies, such as declarative policies, can be defined as 1393 subclasses of SUPAPolicyStructure in the future. 1395 A 1396 +---------------------+ 1397 | SUPAPolicyStructure | 1398 +--------+------------+ 1399 / \ 1400 I 1401 I 1402 +---------------+----------------+ 1403 I I 1404 C I A I 1405 +----------------+---------------+ +-----------+-----------+ 1406 | Future Subclasses to Represent | | SUPAECAPolicyRule | 1407 | Represent Different Policies | +-----------------------+ 1408 +--------------------------------+ 1410 Figure 5. The Composite Pattern Applied to SUPAPolicyStructure 1412 4.4.2. Representing an ECA Policy Rule 1414 An ECA policy rule is a 3-tuple, which is made up of an event 1415 clause, a condition clause, and an action clause. Each of these 1416 three types of clauses may in turn be made up of a Boolean 1417 combination of clauses of that type. Each clause may be viewed as 1418 a predicate, as it provides a TRUE or FALSE output. The canonical 1419 form of a clause is a 3-tuple of the form "variable operator value", 1420 and can be made into more complex Boolean expressions. For example, 1421 the SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two 1422 clauses, "(A AND B)" and "(C OR D)", that are combined together 1423 using the operators OR and NOT. 1425 A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract 1426 subclass of SUPAPolicyStructure. 1428 A A 1429 +---------------------------+ +------------------+ 1430 | SUPAPolicyStructure | | SUPAPolicyClause | 1431 +---------+---------+-------+ +--------+----+----+ 1432 / \ / \ 0..1 1..n / \ / \ 1433 I A | I 1434 I \ / | I 1435 I | | I 1436 I | SUPAHasPolicyClause | I 1437 I +------------------------+ I 1438 A I A I 1439 +------+------------+ +----------+-------+ 1440 | SUPAECAPolicyRule | | SUPAPolicyClause | 1441 +-------------------+ +------------------+ 1443 Figure 6. SUPAECAPolicyRule Aggregating SUPAPolicyClauses 1445 Note that the aggregation SUPAHasPolicyClause in Figure 6 is 1446 realized as an association class, in order to manage which set 1447 of SUPAPolicyClauses can be aggregated by which set of 1448 SUPAECAPolicyRules. This aggregation is defined at the 1449 SUPAPolicyStructure level, and not at the lower level of 1450 SUPAECAPolicyRule, so that non-ECA policies can also use this 1451 aggregation. 1453 Since a SUPAECAPolicyRule consists of three SUPAPolicyClauses, 1454 at least three separate instances of the SUPAHasPolicyClause 1455 aggregation are instantiated in order to make a complete 1456 SUPAECAPolicyRule, as shown in Figure 7. 1458 A A 1459 +-------------------+ +--------------------+ 1460 | SUPAECAPolicyRule | | SUPAPolicyClause | 1461 +--+----+----+------+ +-------+----+----+--+ 1462 / \ / \ / \ 1..n 0..n / \ / \ / \ 1463 A A A | | | 1464 \ / \ / \ / | | | 1465 | | | | | | 1466 | | | SUPAHasPolicyClause #1 | | | 1467 | | +------------------------------+ | | 1468 | | | | 1469 | | SUPAHasPolicyClause #2 | | 1470 | +----------------------------------------+ | 1471 | | 1472 | SUPAHasPolicyClause #3 | 1473 +--------------------------------------------------+ 1475 note: all 3 aggregations have a multiplicity of 1..n - 0..n 1477 Figure 7. Instantiating a SUPAECAPolicyRule, part 1 1479 In figure 7, SUPAECAPolicyRule is shown as "owning" these three 1480 aggregations, since it inherits them from its superclass 1481 (SUPAPolicyStructure). The three aggregations represent the 1482 event, condition, and action clauses of a SUPAECAPolicyRule. 1483 Note that each of these clauses MAY consist of one or more 1484 SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist 1485 of one or more predicates. In this way, complex event, condition, 1486 and action clauses, which are combinations of Boolean expressions 1487 that form a logical predicate) are supported, without having to 1488 define additonal objects (as is done in previous work; please 1489 see Appendix A for a comparison to previous work. 1491 The multiplicity of the SUPAHasPolicyClause aggregation is 1492 0..n on the aggregate side and 1..n on the part side. This means 1493 that a particular SUPAECAPolicyRule MUST aggregate at least one 1494 SUPAPolicyClause, and that a given SUPAPolicyClause MAY be 1495 aggregated by zero or more SUPAECAPolicyRule objects. 1497 This cardinality MAY be refined to 3..n for SUPAECAPolicyRules, 1498 since a SUPAECAPolicyRule MUST have at least three separate clauses. 1499 However, since a SUPAPolicyStructure is the owner of this 1500 aggregation (which is inherited by SUPAECAPolicyRule), the 1501 cardinality is defined to be 1..n on the part side because other 1502 types of Policies have different needs. The 0..n cardinality 1503 means that a SUPAPolicyClause may be aggregated by zero or more 1504 SUPAECAPolicyRules. The zero is provided so that SUPAPolicyClauses 1505 can be stored in (for example) a repository before the 1506 SUPAECAPolicyRule is created; the "or more" recognizes the fact 1507 that multiple SUPAECAPolicyRules could aggregate the same 1508 SUPAPolicyClause. 1510 In Figure 7, suppose that SUPAHasPolicyClause#1, #2, and #3 1511 represent the aggregations for the event, condition, and action 1512 clauses, respectively. This means that each of these 1513 SUPAHasPolicyClause aggregations must explicitly identify the 1514 type of clause that it represents. 1516 In looking at Figure 7, there is no difference between any of the 1517 three aggregations, except for the type of clause that the 1518 aggregation represents (i.e., event, condition, or action clause). 1520 Therefore, three different aggregations, each with their own 1521 association class, is not needed. Instead, the GPIM defines a 1522 single aggregation (SUPAHasPolicyClause) that is realized using a 1523 (single) abstract association class (SUPAHasPolicyClauseDetail); 1524 this association class is then subclassed into three concrete 1525 subclasses, one each to represent the semantics for an event, 1526 condition, and action clause. 1528 The policy management system may use any number of different 1529 software mechanisms, such as introspection or reflection, to 1530 determine the nature of the aggregation (i.e., what object types 1531 are being aggregated) in order to select the appropriate subclass 1532 of SUPAHasPolicyClauseDetail. The three subclasses of 1533 SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail, 1534 SUPAHasPolicyConditionDetail, and SUPAHasPolicyActionDetail, 1535 respectively. While Event, Condition, and Action objects are 1536 typically used in ECA policy rules, the design in this document 1537 enables them to be used as policy components of other types of 1538 policies as well. This is shown in Figure 8. 1540 A A 1541 +-------------------+ +------------------+ 1542 | SUPAECAPolicyRule | | SUPAPolicyClause | 1543 +---------+---------+ +----------+-------+ 1544 / \ 1..n 0..n / \ 1545 A | 1546 \ / | 1547 | | 1548 | SUPAHasPolicyClause | 1549 +--------------+-----------------+ 1550 ^ 1551 | 1552 A | 1553 +--------------+------------+ 1554 | SUPAHasPolicyClauseDetail | 1555 +--------------+------------+ 1556 / \ 1557 I 1558 I 1559 +----------------+-----------------------+ 1560 I I I 1561 C I C I C I 1562 +--------+-----+ +-------+----------+ +---------+-----+ 1563 |Event subclass| |Condition subclass| |Action subclass| 1564 +--------------+ +------------------+ +---------------+ 1566 Figure 8. Instantiating a SUPAECAPolicyRule, part 2 1568 4.4.3. Creating SUPA Policy Clauses 1570 There are two different types of Policy Components. They are a 1571 SUPAPolicyClause and a SUPAPolicyComponentDecorator. The former 1572 is used to construct SUPAECAPolicyRules, while the latter is used 1573 to add behavior to a SUPAPolicyClause. This enables the structure 1574 and capabilities of the SUPAPolicyClause to be adjusted 1575 dynamically at runtime. 1577 However, since each SUPAECAPolicyRule can be made up of a variable 1578 number of SUPAPolicyComponents, the decorator pattern is used to 1579 "wrap" any concrete subclass of SUPAPolicyClause with zero or more 1580 concrete subclasses of the PolicyComponentDecorator object. This 1581 avoids problems of earlier models that resulted in a proliferation 1582 of classes and relationships. 1584 Figure 9 shows these two class subclasses. Note that the decorator 1585 pattern [11] is used to enable subclasses of the 1586 SUPAPolicyComponentDecorator class to add their attributes and/or 1587 behavior to a SUPAPolicyClause (as stated in section 4.3) without 1588 affecting the behavior of other objects from the same class. More 1589 specifically, concrete subclasses of the (abstract) 1590 SUPAPolicyComponentDecorator class can be used to decorate, or 1591 "wrap", any of the concrete subclasses of the (abstract) 1592 SUPAPolicyClause class. 1594 A 1595 +------------------------------+ 1..n 1596 | SUPAPolicyComponentStructure +----------------------+ 1597 +----------------+-------------+ | 1598 / \ | 1599 I SUPAHasPolicyComponentDecorators | 1600 I | 1601 +--------------+-----------+ | 1602 I I | 1603 A I A I | 1604 +---------+--------+ +--------------+---------------+ 0..1 | 1605 | | | |/ \ | 1606 | SUPAPolicyClause | | SUPAPolicyComponentDecorator + A -----+ 1607 | | | |\ / 1608 +------------------+ +------------------------------+ 1610 Figure 9. Subclasses of SUPAPolicyComponentStructure 1612 Instead of using inheritance to statically create new classes to 1613 represent new types of objects, the decorator pattern uses 1614 composition to dynamically combine attributes and behavior from 1615 existing objects into new objects. This is done by defining an 1616 interface in SUPAPolicyComponent that all of the subclasses of 1617 SUPAPolicyComponent conform to. Since the subclasses are of the 1618 same type as SUPAPolicyComponent, they all have the same interface. 1619 This allows each concrete SUPAPolicyComponentDecorator subclass to 1620 add its attributes and/or behavior to the concrete subclass of 1621 SUPAPolicyClause that it is decorating (or "wrapping"). 1623 This represents an important design optimization for data models. 1624 Note that a single SUPAECAPolicyRule can consist of any number of 1625 SUPAPolicyClauses, each of very different types. If inheritance 1626 was used, then a subclass AND an aggregation would be required for 1627 each separate clause that makes up the policy rule. 1629 Clearly, continuing to create subclasses is not practical. Worse, 1630 suppose composite objects are desired (e.g., a new object Foo is 1631 made up of existing objects Bar and Baz). If all that was needed 1632 was one attribute of Bar and two of Baz, the developer would still 1633 have to use the entire Bar and Baz classes. This is wasteful and 1634 inefficient. In contrast, the decorator pattern enables all, or 1635 just some, of the attributes and/or behavior of a class to "wrap" 1636 another class. This is used heavily in many production systems 1637 (e.g., the java.io package) because the result is only the 1638 behavior that is required, and no other objects are affected. 1640 The SUPAPolicyComponentDecorator class hierarchy is used to define 1641 objects that may be used to construct a SUPAPolicyClause. The 1642 decorator object can add behavior before, and/or after, it 1643 delegates to the object that it is decorating. The subclasses of 1644 SUPAPolicyComponentDecorator provide a very flexible and completely 1645 dynamic mechanism to: 1647 1) add or remove behavior to/from an object 1648 2) ensure that objects are constructed using the minimum amount 1649 of features and functionality required 1651 SUPAPolicyComponentDecorator defines four subclasses, as shown in 1652 Figure 10. 1653 A 1654 +------------------------------+ 1655 | SUPAPolicyComponentDecorator | 1656 +--------------+---------------+ 1657 / \ 1658 I 1659 I 1660 I 1661 +------------+-------------+----------------+ 1662 I I I I 1663 A I I C I I 1664 +--------+-------+ I +---------+------------+ I 1665 | SUPAPolicyTerm | I | SUPAPolicyCollection | I 1666 +----------------+ I +----------------------+ I 1667 (for defining I (for defining sets and/or I 1668 clauses in a I groups of objects) I 1669 canonical form) I I 1670 I I 1671 C I A I 1672 +----------------+--------------+ +---------+--------+ 1673 | SUPAGenericDecoratedComponent | | SUPAECAComponent | 1674 +-------------------------------+ +------------------+ 1675 (for decorating concrete (for defining reusable 1676 subclasses of SUPAPolicyClause) event, condition, 1677 and action objects) 1679 Figure 10. Subclasses of SUPAPolicyComponentDecorator 1681 If a SUPAEncodedClause is being used, then there is no need to 1682 use any of the SUPAPolicyComponentDecorator subclasses, since 1683 the SUPAEncodedClause already completely defines the content of 1684 the SUPAPolicyClause. 1686 However, if a SUPAEncodedClause is NOT being used, then a 1687 SUPAPolicyClause will be constructed using one or more types of 1688 objects that are each subclasses of SUPAPolicyComponentDecorator. 1690 These four subclasses provide four different ways to construct a 1691 SUPAPolicyClause: 1693 1) SUPAPolicyTerm: as a {variable, operator, value} clause 1694 2) SUPAEncodedClause: as an encoded object (e.g., to pass YANG 1695 or CLI code) 1696 3) SUPAPolicyCollection: as a collection of objects that 1697 requires further processing in order to be made into a 1698 SUPAPolicyClause 1699 4) SUPAECAComponent: subclasses define reusable Event, 1700 Condition, or Action objects 1702 These four different types of objects can be intermixed. For 1703 example, the first and last types can be combined as follows: 1705 Variable == Event.baz (A) 1706 Condition BETWEEN VALUE1 and VALUE2 (B) 1707 (Event.severity == 'Critical' AND 1708 (SLA.violation == TRUE OR User.class == 'Gold')) (C) 1710 In the above rules, (A) uses Event.baz to refer to an attribute 1711 of the Event class; (B) defines two different instances of a Value 1712 class, denoted as Value1 and Value2; (C) uses the nomenclature 1713 foo.bar, where foo is the name of a class, and bar is the name of 1714 an attribute of that class. 1716 4.4.4. Creating SUPAPolicyClauses 1718 The GPIM defines a single subclass of SUPAPolicyClause, called 1719 SUPAEncodedClause. This clause is generic in nature, and MAY be 1720 used with any type of policy (ECA or otherwise). The EPRIM 1721 defines an ECA-specific subclass of the GPIM, called a 1722 SUPABooleanClause, which is intended to be used with just 1723 ECA policy rules; however, other uses are also possible. 1725 Together, the GPIM and EPRIM provide several alternatives to 1726 implement a SUPAPolicyClause, enabling the developer to 1727 optimize the solution for different constraints: 1729 1) The SUPAPolicyClause can be encoded using one or more 1730 SUPAEncodedClauses; a SUPAEncodedClause encodes the 1731 entire content of its respective event, condition, or 1732 action clause. 1733 2) The SUPAPolicyClause can be defined using one or more 1734 SUPABooleanClauses; each of the three clauses can be 1735 defined as either a single SUPABooleanClause, or a 1736 combination of SUPABooleanClauses that are logically 1737 ANDed, ORed, and/or NOTed. 1738 3) The above two mechanisms can be combined (e.g., the first 1739 used to define the event clause, and the second used to 1740 define the condition and action clauses). 1742 Figure 11 shows the subclasses of SUPAPolicyClause. 1744 A 1745 +------------------+ 1746 | SUPAPolicyClause | 1747 +--------+---------+ 1748 / \ 1749 I 1750 I 1751 I 1752 +---------------+-------------+ 1753 I I 1754 A I C I 1755 +--------+----------+ +----------+--------+ 1756 | SUPABooleanClause | | SUPAEncodedClause | 1757 +-------------------+ +-------------------+ 1759 Figure 11. Subclasses of SUPAPolicyClause 1761 SUPABooleanClause is defined in the EPRIM, and is used to 1762 construct Boolean clauses that collectively make up a 1763 SUPAPolicyClause. It is abstract, so that the composite pattern 1764 can be applied to it, which enables hierarchies of Boolean 1765 clauses to be created. SUPAEncodedClause (see section 6.7) is 1766 used to encode the content of a SUPAPolicyClause as an attribute 1767 (instead of reusable objects). 1769 4.4.5. SUPAPolicySources 1771 A SUPAPolicySource is a set of managed entities that authored, 1772 or are otherwise responsible for, this SUPAPolicy. Note that a 1773 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 1774 primary use is for auditability, authorization policies, and 1775 other applications of deontic and/or alethic logic. 1777 SUPAPolicyStructure defines four relationships. Two of these 1778 (SUPAHasPolicySource and SUPAHasPolicyTarget), which are both 1779 aggregations, relate a SUPAPolicyStructure to a SUPAPolicySource 1780 and a SUPAPolicyTarget, respectively. Since SUPAECAPolicyRule is 1781 a subclass of SUPAPolicyStructure, it (and its subclasses) inherit 1782 both of these aggregations. This enables SUPAPolicySources and/or 1783 SUPAPolicyTargets to be attached to SUPAECAPolicyRules (but NOT to 1784 components of a SUPAPolicy). 1786 Figure 12 shows how SUPAPolicySources and SUPAPolicyTargets are 1787 attached to a SUPAPolicy. Note that both of these aggregations 1788 are defined as optional, since their multiplicity is 0..n - 0..n. 1789 In addition, both of these aggregations are realized as 1790 association classes, in order to be able to control which 1791 SUPAPolicySources and SUPAPolicyTargets are attached to a given 1792 SUPAECAPolicyRule. 1794 A 1795 +------------------+ 1796 | SUPAPolicyObject | 1797 +--------+---------+ 1798 / \ 1799 I 1800 I 1801 I 1802 +--------------+-----+---------------------+ 1803 I I I 1804 A I C I C I 1805 +-----------+---------+ +-------+--------+ +--------+-------+ 1806 | SUPAPolicyStructure | |SUPAPolicySource| |SUPAPolicyTarget| 1807 +------+-------+------+ +----------+-----+ +----------+-----+ 1808 0..n / \ / \ 0..n 0..n / \ 0..n / \ 1809 A A | | 1810 \ / \ / | | 1811 | | | | 1812 | | | | 1813 | +--------------------+ | 1814 | SUPAHasPolicySource | 1815 | | 1816 +-------------------------------------------------+ 1817 SUPAHasPolicyTarget 1819 Figure 12. ECAPolicyRules, SUPAPolicySources, and PolicyTargets 1821 A SUPAPolicySource MAY be mapped to a role (e.g., using the 1822 role-object pattern [11]); this indirection makes the system less 1823 fragile, as entities can be transparently added or removed from 1824 the role definition without adversely affecting the definition of 1825 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 1826 SUPAPolicyMetadata. 1828 4.4.6. SUPAPolicyTargets 1830 A SUPAPolicyTarget defines the set of managed entities that a 1831 SUPAPolicy is applied to. This is useful for debugging, as well as 1832 when the nature of the application requires the set of managed 1833 entities affected by a Policy to be explicitly identified. This is 1834 determined by two conditions: 1836 1) The set of managed entities that are to be affected by the 1837 SUPAPolicy must all agree to play the role of a 1838 SUPAPolicyTarget. For example, a managed entity may not be 1839 in a state that enables SUPAPolicies to be applied to it; 1840 hence, in this case, it MUST NOT assume the role of a 1841 SUPAPolicyTarget 1842 2) A SUPAPolicyTarget must be able to: 1843 a) process (either directly or with the aid of a proxy) 1844 SUPAPolicies, or 1845 b) receive the results of a processed SUPAPolicy and 1846 apply those results to itself. 1848 Figure 12 showed how SUPAPolicyTargets are attached to 1849 SUPAECAPolicyRules. 1851 A SUPAPolicyTarget MAY be mapped to a role (e.g., using the 1852 role-object pattern [11]); this indirection makes the system less 1853 fragile, as entities can be transparently added or removed from 1854 the role definition without adversely affecting the definition of 1855 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 1856 SUPAPolicyMetadata. 1858 4.4.7. Policy Metadata 1860 Metadata is, literally, data about data. As such, it can be 1861 descriptive or prescriptive in nature. 1863 4.4.7.1. Motivation 1865 There is a tendency in class design to make certain attributes, 1866 such as description, status, validFor, and so forth, bound to a 1867 specific class (e.g., [6]). This is bad practice in an information 1868 model. For example, different classes in different parts of the 1869 class hierarchy could require the use of any of these attributes; 1870 if one class is not a subclass of the other, then they must each 1871 define the same attribute as part of their class structure. This 1872 makes it difficult to find all instances of the attribute and 1873 ensure that they are synchronized. Furthermore, context can 1874 dynamically change the status of an object, so an easy way to 1875 update the status of one object instance without affecting other 1876 instances of the same object is required. 1878 Many models, such as [4] and [6], take a simplistic approach of 1879 defining a common attribute high in the hierarchy, and making it 1880 optional. This violates classification theory, and defeats the 1881 purpose of an information model, which is to specify the 1882 differences in characteristics and behavior between classes (as 1883 well as define how different classes are related to each other). 1884 Note that this also violates a number of well-known software 1885 architecture principles, including: 1887 o the Liskov Substitution Principle [13] 1888 (if A is a subclass of B, then objects instantiated from 1889 class B may be replaced with objects instantiated from 1890 class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS) 1891 o the Single Responsibility Principle [14] 1892 (every class should have responsibility over one, and only 1893 one, part of the functionality provided by the program) 1894 o the Open/Closed Principle (software should be open for 1895 extension, but closed for modification) [17] 1896 o the Interface-Segreation Principle (clients should not be 1897 forced to depend on methods that they do not use) [14] 1898 o the Dependency Inversion Principle (high-level modules should 1899 not depend on low-level modules; both should depend on 1900 abstractions) [14] 1902 Most models use inheritance, not composition. The former is 1903 simpler, but has some well-known problems. One is called "weak 1904 encapsulaton", meaning that a subclass can use attributes and 1905 methods of a superclass, but if the superclass changes, the 1906 subclass may break. Another is that each time a new object is 1907 required, a new subclass must be created. These problems are 1908 present in [RFC3460], [4], and [6]. 1910 Composition is an alternative that provides code that is easier to 1911 use. This means that composition can provide data models that are 1912 more resistant to change and easier to use. By using composition, 1913 we can select just the metadata objects that are needed, instead 1914 of having to rely on statically defined objects. We can even 1915 create new objects from a set of existing objects through 1916 composition. Finally, we can use the decorator pattern to select 1917 just the attributes and behaviors that are required for a given 1918 instance. 1920 In [2] and [5], a separate metadata class hierarchy is defined to 1921 address this problem. This document follows this approach. 1923 4.4.7.2. Design Approach 1925 The goal of the GPIM is to enable metadata to be attached to any 1926 subclass of SUPAPolicyObject that requires it. Since this is a 1927 system intended for policy-based management, it therefore makes 1928 sense to be able to control which metadata is attached to which 1929 policies dynamically (i.e., at runtime). 1931 One solution is to use the Policy Pattern [1], [2], [6], [12]. 1932 This pattern was built to work with management systems whose 1933 actions were dependent upon context. The Policy Pattern works as 1934 follows: 1936 o Context is derived from all applicable system inputs (e.g., 1937 OAMP data from network elements, business goals, time of 1938 day, geo-location, etc.). 1939 o Context is then used to select a working set of Policies. 1940 o Policies are then used to define behavior at various 1941 control points in the system. 1942 o One simple type of control point is an association class. 1943 Since the association class represents the semantics of how 1944 two classes are related to each other, then 1945 o ECAPolicyRule actions can be used to change the attribute 1946 values, methods, and relationships of the association 1947 class 1948 o This has the affect of changing how the two classes are 1949 related to each other 1950 o Finally, as context changes, the working set of policies 1951 change, enabling the behavior to be adjusted to follow 1952 changes in context (according to appropriate business goals 1953 and other factors, of course) in a closed loop manner. 1955 Conceptually, this is accomplished as shown in Figure 13 below. 1957 Defines 1958 +----------+ Behavior +------------+ 1959 | Policies +----------------+ | SUPAPolicy | 1960 +----+-----+ 1..n | +------+-----+ 1961 0..n / \ | / \ 0..n 1962 | | A 1963 | | \ / 1964 | 1..n \ / | 1965 | +-----------+--------------+ | 1966 | | SUPAPolicyMetadataDetail | | 1967 | +-----------+--------------+ | 1968 | | | 1969 | Selects | | 1970 | Policies | | 1971 | | | 1972 | +-------------------->+ 1973 | Applies | 1974 / \ Behavior | 1975 A | 1976 0..n \ / \ / 0..n 1977 +----+-----+ +--------+---------+ 1978 | Context | |SUPAPolicyMetadata| 1979 +----------+ +------------------+ 1981 Figure 13. Context-Aware Policy Rules 1983 4.4.7.2.1. Policies and Actors 1985 The Policy Continuum ([1] [5] [10] [12]) was defined to associate 1986 different actors with different policies at different levels of 1987 business and/or technical specificity. Context-aware policy rules, 1988 and the Policy Pattern, were defined to realize this association. 1990 Four important functions related to the lifecycle of policies are 1991 design, implementation, deployment, and execution. There are many 1992 different possible definitions of these functions (even for policy 1993 lifecycle management); however, for the purposes of this document, 1994 they are defined as follows: 1996 o Design: The process of defining a software architecture 1997 to satisfy user requirements. 1998 o Development: the process of documenting, programming, 1999 testing, and maintaining code and applications 2000 as part of a software product 2001 o Deployment: the process that assembles and transfers 2002 completed software artifacts to a state that 2003 enables their execution 2004 o Execution: the process of installing, activating, running, 2005 and subsequently deactivating executable 2006 software products 2008 The design process is responsible for producing a software 2009 architecture. This emphasizes the design, as opposed to the 2010 programming, of software systems. In contrast to design, 2011 development emphasizes constructing software artifacts via coding 2012 and documentation. 2014 Deployment may be described as the process of releasing software. 2015 It includes all of the operations required to assemble a completed 2016 software product. It typically also includes the process of 2017 preparing a software product for execution (e.g., assembling a set 2018 of software products into a larger product, determining if the 2019 consumer site has appropriate resources to install and execute the 2020 software product, and collecting information on the feasibility of 2021 using the software product). This contrasts with the execution 2022 process, which is the set of processes that follow deployment. 2024 In summary, exemplar states in the policy lifecycle process 2025 include: 2027 o Design: determining how the policy-based management 2028 system will operate 2029 o Development: documenting, programming, testing, and 2030 maintaining policies and policy components 2031 o Deployment: assembling the components of a policy-based 2032 management system 2033 o Execution: installing, enabling, running, disabling, 2034 and uninstalling policies and policy components 2036 4.4.7.2.2. Deployment vs. Execution of Policies 2038 One of the primary reasons for separating the deployment and 2039 execution processes is to differentiate between environments that 2040 are not ready to execute policies (i.e., deployment) and 2041 environments that are ready to execute policies (i.e., execution). 2042 This is an important consideration, since policies that are 2043 related to the same set of tasks may be deployed in many different 2044 places (e.g., in a policy system vs. in a network device). In 2045 addition, each managed entity in the set of SUPAPolicyTargets may 2046 or may not be in a state that allows SUPAPolicies to be applied to 2047 it (see section 4.4.6.). 2049 Hence, this design includes dedicated class attributes for 2050 getting and setting the deployment and execution status, as well 2051 as enabling and disabling, SUPAPolicies (see section 5.3.1.). 2053 4.4.7.2.3. Using SUPAMetadata for Policy Deployment and Execution 2055 One way of encoding deployment and execution status for policies 2056 and policy components is to attach Metadata objects to affected 2057 SUPAPolicyStructure and SUPAPolicyComponentStructure objects. 2058 This provides an extensible and efficient means to describe 2059 and/or prescribe deployment and/or execution status of a policy 2060 or a policy component. It is extensible, since classes and 2061 relationships can be used, as opposed to a set of attributes. It 2062 is efficient, because the decorator pattern (see section 5.7) is 2063 used (this enables attributes and/or methods of objects, or the 2064 entire object, to be used to add characteristics and/or behavior 2065 to a given object. 2067 SUPAPolicyMetadata objects (see sections 5.16 - 5.20) may be 2068 attached to the SUPAECAPolicyRule and/or any of its components 2069 to define additional semantics of the SUPAECAPolicyRule. For 2070 example, SUPAAccessMetadataDef (see section 5.19) and/or 2071 SUPAVersionMetadataDef (see section 5.20) may be attached to 2072 define the access privileges and version information, 2073 respectively, of a policy rule and/or its components. 2075 The SUPAPolicyStructure defines an attribute, supaPolDeployStatus, 2076 (see section 5.3.1.3.) that SUPAPolicyMetadata objects can 2077 use to get and set the deployment and execution status of a 2078 SUPAPolicy. This allows metadata to be used to alter the 2079 deployment and/or execution state of a policy (or a set of 2080 policy components) without having to affect other parts of the 2081 policy-based management system. The supaPolDeployStatus attribute 2082 indicates that this SUPAPolicy can or cannot be deployed. If it 2083 cannot be deployed. Similarly, the supaPolExecStatus attribute 2084 is used to indicate if a particular SUPAPolicy has executed, is 2085 currently executing, or is ready to execute, and whether or not 2086 the execution of that SUPAPolicy had any failures. 2088 The reverse is also true (and hence, forms a closed-loop system 2089 controlled by metadata). For example, if the set of deployed 2090 SUPAPolicies are SUPAECAPolicyRules, then when the actions of 2091 these SUPAECAPolicyRules are executed, the overall context has 2092 changed (see section 4.4.7.2). The context manager could then 2093 change attribute values (directly or indirectly) in the 2094 SUPAPolicyMetadataDetail association class. This class represents 2095 the behavior of the SUPAHasPolicyMetadata aggregation, which is 2096 used to define which SUPAPolicyMetadata can be attached to which 2097 SUPAPolicy objet in this particular context. For example, the 2098 access privileges of a policy and/or policy component could be 2099 changed dynamically, according to changes in context. 2101 By using the decorator pattern on SUPAPolicyMetadata, any number 2102 of SUPAPolicyMetadata objects (or their attributes, etc.) can be 2103 wrapped around a concrete subclass of SUPAPolicyMetadata. This is 2104 shown in Figure 14 below. 2106 4.4.7.3. Structure of SUPAPolicyMetadata 2108 SUPAPolicyMetadata also uses the decorator pattern to provide an 2109 extensible framework for defining metadata to attach to SUPAPolicy 2110 subclasses. Its two principal subclasses are 2111 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. The 2112 former is used to define concrete subclasses of SUPAPolicyMetadata 2113 that are attached at runtime to SUPAPolicy subclasses, while the 2114 latter is used to define concrete objects that represent reusable 2115 attributes, methods, and relationships that can be added to 2116 subclasses of SUPAPolicyConcreteMetadata. 2118 For example, concepts like identification, access control, and 2119 version information are too complex to represent as a single 2120 attribute, or even a couple of attributes - they require the 2121 generic power of objects to represent their characteristics and 2122 behavior. Furthermore, defining concrete classes to represent 2123 these concepts in the policy hierarchy is fragile, because: 2125 1. not all objects that use these concepts need all of the 2126 information represented by them (e.g., two subclasses of an 2127 Identification Object may be Passport and Certificate, but 2128 these two objects are rarely used together, and even those 2129 contexts that use one of these classes may not need all of 2130 the data in that class) 2131 2. defining a class means defining its attributes, methods, and 2132 relationships at a particular place in the hierarchy; this 2133 means that defining a relationship between a class A and 2134 another class B SHOULD only be done if all of the subclasses 2135 of B can use the attributes, methods, and relationships of A 2136 (e.g., in the above example, defining a relationship between 2137 an Identification Object and a superclass of a router class 2138 is not appropriate, since routers do not use Passports) 2140 A 2141 +------------------+ 2142 | SUPAPolicyObject | 2143 +--------+---------+ 2144 / \ 0..n 2145 A 2146 \ / 2147 | A 2148 | 0..n +--------------------+ 2149 | SUPAHasPolicyMetadata \| | 2150 +-------------+-----------------+ SUPAPolicyMetadata | 2151 ^ /| | 2152 | +------+------+------+ 2153 C | / \ | 1..n 2154 +-------------+---------------+ I | 2155 1..n | | I | 2156 +----------+ SUPAHasPolicyMetadataDetail | I | 2157 | | | I | 2158 | +-----------------------------+ I | 2159 | I | 2160 | (gets/sets values of attributes and/or I | 2161 | methods of the SUPAHasPolicyMetadataDetail I | 2162 | class; this affects which SUPAPolicyMetadata I | 2163 | objects can be attached to which policies I | 2164 | and policy components) I | 2165 | I | 2166 | C I | 2167 | +----------------------------+ I | 2168 | | | I | 2169 +----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+ | 2170 | | I | 2171 +----------------------------+ I | 2172 I | 2173 A I | 2174 +-----------------------------+ I | 2175 | | I | 2176 | SUPAPolicyMetadataDecorator +IIIIIIIII+ | 2177 | | | 2178 +-------+--------------+------+ | 2179 / \ / \ 0..1 | 2180 I A | 2181 I \ / | 2182 I | | 2183 subclasses for adding | | 2184 behavior to policies +-----------------------+ 2185 and policy components SUPAHasMetadataDecorator 2187 Figure 14. SUPAPolicyMetadata Subclasses and Relationships 2189 Since a class encapsulates attributes, methods, and behavior, 2190 defining the Identification Object in the above example as a type 2191 of SUPAPolicyMetadata object enables the decorator pattern to be 2192 used to attach all or part of that object to other objects that 2193 need it. 2195 Figure 15 shows a portion of the SUPAPolicyMetadata hierarchy. 2197 A 2198 +--------------------+ 2199 | | SUPAHasMetadataDecorator 2200 | SUPAPolicyMetadata +-------------------+ 2201 | | 1..n | 2202 +---------+----------+ | 2203 I | 2204 I | 2205 I | 2206 +-------------+-----------------+ | 2207 | | | 2208 C | | / \ 2209 +---------+------------------+ | A 2210 | SUPAPolicyConcreteMetadata | A | 0..1 \ / 2211 +----------------------------+ +--------+------------+-------+ 2212 | SUPAPolicyMetadataDecorator | 2213 +------------+----------------+ 2214 I 2215 +------------------------------+--------+ 2216 I I 2217 I I 2218 C I C I 2219 +---------------+-------------+ +---------------------+--------+ 2220 | SUPAPolicyAccessMetadataDef | | SUPAPolicyVersionMetadataDef | 2221 +-----------------------------+ +------------------------------+ 2223 Figure 15. SUPAPolicyMetadata Subclasses and Relationships 2225 Figure 15 shows a relevant portion of the SUPAPolicyMetadata 2226 hierarchy. SUPAPolicyConcreteMetadata is a concrete class that 2227 subclasses of the SUPAPolicyMetadataDecorator class can wrap. 2228 Two such subclasses, SUPAPolicyAccessMetadataDef and 2229 SUPAPolicyVersionMetadataDef, are shown in Figure 15. This 2230 enables access control and version information to be added 2231 statically (at design time) or dynamically (at runtime) to 2232 SUPAPolicyConcreteMetadata; this enables metadata-driven systems 2233 to adjust the behavior of the management system to changes in 2234 context, business rules, services given to end-users, and other 2235 similar factors. This is discussed more in sections 5.18 - 5.20. 2237 4.5. Advanced Features 2239 This section will be completed in the next revision of this 2240 document. 2242 4.5.1. Policy Grouping 2244 This section will be completed in the next revision of this 2245 document. 2247 4.5.2. Policy Rule Nesting 2249 This section will be completed in the next revision of this 2250 document. 2252 5. GPIM Model 2253 This section defines the classes, attributes, and relationships of 2254 the GPIM. 2256 5.1. Overview 2257 The overall class hierarchy is shown in Figure 16; section numbers 2258 are appended after each class. 2260 (Class of another model that SUPA is integrating into) 2261 | 2262 +---SUPAPolicyObject (5.2) 2263 | | 2264 | +---SUPAPolicyStructure (5.3) 2265 | | 2266 | +---SUPAPolicyComponentStructure (5.4) 2267 | | | 2268 | | +---SUPAPolicyClause (5.5) 2269 | | | | 2270 | | | +---SUPAEncodedClause (5.6) 2271 | | | 2272 | | +---SUPAPolicyComponentDecorator (5.7) 2273 | | | 2274 | | +---SUPAPolicyTerm (5.8) 2275 | | | | 2276 | | | +---SUPAPolicyVariable (5.9) 2277 | | | | 2278 | | | +---SUPAPolicyOperator (5.10) 2279 | | | | 2280 | | | +---SUPAPolicyValue (5.11) 2281 | | | 2282 | | +---SUPAGenericDecoratedComponent (5.12) 2283 | | | 2284 | | +---SUPAPolicyCollection (5.13) 2285 | | 2286 | +---SUPAPolicySource (5.14) 2287 | | 2288 | +---SUPAPolicyTarget (5.15) 2290 (Class of another model that SUPAPolicyMetadata is integrating into) 2291 | 2292 +---SUPAPolicyMetadata (5.16) 2293 | 2294 +---SUPAPolicyConcreteMetadata (5.17) 2295 | 2296 +---SUPAPolicyMetadataDecorator (5.18) 2297 | 2298 +---SUPAPolicyAccessMetadataDef (5.19) 2299 | 2300 +---SUPAPolicyVersionMetadataDef (5.20) 2302 Figure 16: Main Classes of the GPIM 2304 SUPAPolicy is the root of the SUPA class hierarchy. For 2305 implementations, it is assumed that SUPAPolicy is subclassed from 2306 a class from another model. Note that SUPAPolicyMetadata MAY be 2307 subclassed from the same or (preferably) a different class in the 2308 external model. 2310 Classes, attributes, and relationships that are marked as 2311 "mandatory" MUST be part of a conformant implementation (i.e., a 2312 schema MUST contain these entities). This does not mean that these 2313 entities must be instantiated; rather it means that they must be 2314 able to be instantiated. Classes, attributes, and relationships 2315 that are marked as "optional" MAY be part of a conformant 2316 implementation. 2318 Unless otherwise stated, all classes (and attributes) defined in 2319 this section were abstracted from DEN-ng [2], and a version of 2320 them are in the process of being added to [5]. However, the work 2321 in [5] has been put on hold, and the names of many of the classes, 2322 attributes, and relationships are slightly different. 2324 5.2. The Abstract Class "SUPAPolicyObject" 2326 This is a mandatory abstract class. Figure 17 shows the 2327 SUPAPolicyObject class, and its four subclasses. 2329 A 0..n 0..n A 2330 +----------------+/ \ \+------------------+ 2331 |SUPAPolicyObject+ A --------------------------+SUPAPolicyMetadata| 2332 +--------+-------+\ / SUPAHasPolicyMetadata /+------------------+ 2333 / \ 2334 I 2335 I 2336 +-----------------+----------------+-----------+ 2337 I I I I 2338 A I I I I 2339 +--------+------------+ I I I 2340 | SUPAPolicyStructure | I I I 2341 +---------------------+ I I I 2342 A I I I 2343 +-----------------+------------+ I I 2344 | SUPAPolicyComponentStructure | I I 2345 +------------------------------+ I I 2346 C I I 2347 +---------+--------+ I 2348 | SUPAPolicyTarget | I 2349 +------------------+ I 2350 C I 2351 +----------+-------+ 2352 | SUPAPolicySource | 2353 +------------------+ 2355 Figure 17. SUPAPolicyObject and Its Subclasses 2357 This class is the root of the SUPA class hierarchy. It defines the 2358 common attributes and relationships that all SUPA subclasses 2359 inherit. 2361 A SUPAPolicyObject MAY be qualified by a set of zero or more 2362 SUPAPolicyMetadata objects. This is provided by the 2363 SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This 2364 enables the semantics of the SUPAPolicyObject to be more 2365 completely specified. 2367 5.2.1. SUPAPolicyObject Attributes 2369 This section defines the attributes of the SUPAPolicyObject class. 2370 These attributes are inherited by all subclasses of the GPIM 2371 except for the SUPAPolicyMetadata class, which is a sibling class. 2373 5.2.1.1. Object Identifiers 2375 This document defines two class attributes in SUPAPolicyObject, 2376 called supaPolObjIDContent and supaPolObjIDEncoding, that together 2377 define a unique object ID. This enables all class instances to be 2378 uniquely identified. 2380 One of the goals of SUPA is to be able to generate different data 2381 models that support different types of protocols and repositories. 2382 This means that the notion of an object ID must be generic. It is 2383 inappropriate to use data modeling concepts, such as keys, Globally 2384 Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs), 2385 Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names 2386 (FQPNs), Uniform Resource Identifiers (URIs), and other similar 2387 mechanisms, to define the structure of an information model. 2388 Therefore, a synthetic object ID is defined using these two class 2389 attributes. This can be used to facilitate mapping to different data 2390 model object schemes. 2392 The two attributes work together, with the supaPolObjIDContent 2393 attribute defining the content of the object ID and the 2394 supaPolObjIDEncoding attribute defining how to interpret the 2395 content. These two attributes form a tuple, and together enable 2396 a machine to understand the syntax and value of an object 2397 identifier for the object instance of this class. 2399 Similarly, all SUPA classes are attributes are both uniquely 2400 named as well as prepended with the prefixes "SUPA" and "supa", 2401 respectively, to facilitate model integration. 2403 5.2.1.2. The Attribute "supaPolObjIDContent" 2405 This is a mandatory string attribute that represents part of the 2406 object identifier of an instance of this class. It defines the 2407 content of the object identifier. It works with another class 2408 attribute, called supaPolObjIDEncoding, which defines how to 2409 interpret this attribute. These two attributes form a tuple, 2410 and together enable a machine to understand the syntax and value 2411 of an object identifier for the object instance of this class. 2412 This is based on the DEN-ng class design [2]. 2414 5.2.1.3. The Attribute "supaPolObjIDEncoding" 2416 This is a mandatory non-zero enumerated integer attribute that 2417 represents part of the object identifier of an instance of this 2418 class. It defines the format of the object identifier. It works 2419 with another class attribute, called supaPolObjIDContent, which 2420 defines the content of the object ID. These two attributes form 2421 a tuple, and together enable a machine to understand the syntax 2422 and value of an object identifier for the object instance of 2423 this class. The supaPolObjIDEncoding attribute is mapped to the 2424 following values: 2426 0: error 2427 1: init 2428 2: primary_key 2429 3: foreign_key 2430 4: GUID 2431 5: UUID 2432 6: URI 2433 7: FQDN 2434 8: FQPN 2435 9: string_instance_id 2437 The values 0 and 1 represent an error state and an initialization 2438 state, respectively. The value 9 defines the canonical 2439 representation, in ASCII, of an instance ID of this object. 2441 5.2.1.4. The Attribute "supaPolicyDescription" 2443 This is an optional string attribute that defines a free-form 2444 textual description of this object. 2446 5.2.1.5. The Attribute "supaPolicyName" 2448 This is an optional string attribute that defines the name of this 2449 Policy. This enables any existing generic naming attribute to be 2450 used for generic naming, while allowing this attribute to be used 2451 to name Policy entities in a common manner. Note that this is NOT 2452 the same as the commonName attribute of the Policy class defined 2453 in [RFC3060], as that attribute is intended to be used with just 2454 X.500 cn attributes. 2456 5.2.2. SUPAPolicyObject Relationships 2458 The SUPAPolicyObject class currently defines a single relationship, 2459 as defined in the subsection below. 2461 5.2.2.1. The Aggregation "SUPAHasPolicyMetadata" 2463 This is a mandatory aggregation that defines the set of 2464 SUPAPolicyMetadata that are aggregated by this particular 2465 SUPAPolicyObject. This aggregation is defined in section 2466 5.16.2. 2468 5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail" 2470 This is a mandatory concrete association class that defines the 2471 semantics of the SUPAPolicyMetadata aggregation. This enables the 2472 attributes and relationships of the SUPAPolicyMetadataDetail class 2473 to be used to constrain which SUPAPolicyMetadata objects can be 2474 aggregated by this particular SUPAPolicyObject instance. This 2475 association class is defined in Section 5.16.2.2. 2477 5.3. The Abstract Class "SUPAPolicyStructure" 2479 This is a mandatory abstract class that is used to represent the 2480 structure of a SUPAPolicy. This class (and all of its subclasses) 2481 is a type of PolicyContainer. SUPAPolicyStructure was abstracted 2482 from DEN-ng [2], and a version of this class is in the process of 2483 being added to [5]. However, the version in [5] differs 2484 significantly. First, the class and relationship definitions ared 2485 different. Second, [5] uses the composite pattern. Neither of 2486 these are implemented in this document because of optimizations 2487 done to the SUPA class hierarchy that are NOT present in [5]. 2489 For this release, the only official type of policy that is 2490 supported is the event-condition-action (ECA) type of policy rule. 2491 However, the structure of the SUPA hierarchy is defined to 2492 facilitate adding new types of rules later. 2494 A SUPAPolicy may take the form of an individual policy or a set 2495 of policies. This requirement is supported by applying the 2496 composite pattern to subclasses of the SUPAPolicyStructure class, 2497 as shown in Figure 5. In this document, this is done for the 2498 SUPAECAPolicyRule subclass, and results in two subclasses: 2499 SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and 2500 SUPAECAPolicyRuleComposite (for defining hierarchies of policies). 2502 Note that there is no need for a "match strategy attribute" that 2503 some models [RFC3460], [4], [6] have; this is because the 2504 SUPAPolicyStructure class is used just for containment. Hence, the 2505 containers themselves serve as the scoping component for nested 2506 policies. 2508 5.3.1. SUPAPolicyStructure Attributes 2510 The following subsections define the attributes of the 2511 SUPAPolicyStructure class. 2513 The SUPAPolicyStructure class has a number of attributes that have 2514 no counterpart in the SUPAPolicyComponentStructure class. This is 2515 because these attributes are only appropriate at the level of a 2516 policy rule, not at the level of a policy component. 2518 Care must be taken in adding attributes to this class, 2519 because the behavior of future subclasses of this class (e.g., 2520 declarative and functional policies) is very different than the 2521 behavior of SUPAECAPolicyRules. 2523 5.3.1.1. The Attribute "supaPolAdminStatus" 2525 This is an optional attribute, which is an enumerated non-negative 2526 integer. It defines the current administrative status of this 2527 SUPAPolicyClause. Values include: 2529 0: error 2530 1: init 2531 2: enabled 2532 3: disabled 2533 4: in test (i.e., no operational traffic can be passed) 2535 The values 0 and 1 represent an error state and an initialization 2536 state, respectively. Values 2 and 3 mean that this 2537 SUPAPolicyStructure is administratively enabled or disabled, 2538 respectively. A value of 4 means that this SUPAPolicyStructure is 2539 currently in a special test mode and SHOULD NOT be used as part of 2540 an OAM&P policy. 2542 5.3.1.2. The Attribute "supaPolContinuumLevel" 2544 This is an optional non-negative integer attribute. It defines 2545 the level of abstraction, or policy continuum level [10], of this 2546 particular SUPAPolicy. The value assignment of this class is 2547 dependent on the application; however, it is recommended that 2548 for consistency with other SUPA attributes, the values of 0 and 1 2549 are reserved for error and initialization states. 2551 By convention, lower values represent more abstract levels of the 2552 policy continuum. For example, a value of 1 could represent 2553 business policy, a value of 2 could represent application-specific 2554 policies, and a value of 3 could represent low=level policies for 2555 network administrators. 2557 5.3.1.3. The Attribute "supaPolDeployStatus" 2559 This is an optional enumerated, non-negative integer attribute. The 2560 purpose of this attribute is to indicate that this SUPAPolicy can 2561 or cannot be deployed by the policy management system. This 2562 attribute enables the policy manager to know which SUPAPolicies to 2563 retrieve, and may be useful for the policy execution system for 2564 planning the staging of SUPAPolicies. Values include: 2566 0: error 2567 1: init 2568 2: deployed and enabled 2569 3: deployed and in test 2570 4: deployed but not enabled 2571 5: ready to be deployed 2572 6: cannot be deployed 2574 The values 0 and 1 represent an error state and an initialization 2575 state, respectively. A value of 2 means that the policy management 2576 system MAY use this SUPAPolicy. A value of 3-5 means that the 2577 policy management system SHOULD NOT use this SUPAPolicy until it is 2578 put into an enabled state. 2580 5.3.1.4. The Attribute "supaPolExecFailStrategy" 2582 This is an optional non-negative, enumerated integer that defines 2583 what actions, if any, should be taken by this 2584 SUPAPolicyStructure object if it fails to execute correctly. 2586 Note that some systems may not be able to support all options 2587 specified in this enumeration. If rollback is supported by the 2588 system, then option 2 may be skipped. Options 3 and 4 can be used 2589 by systems that do and do not support rollback. Values include: 2591 0: error 2592 1: init 2593 2: attempt rollback of all actions taken and stop execution 2594 3: attempt rollback of only the action that failed and stop 2595 execution 2596 4: stop execution but do not rollback any actions 2597 5: ignore failure and continue execution 2599 The values 0 and 1 represent an error state and an initialization 2600 state, respectively. A value of 2 means that ALL execution is 2601 stopped, rollback of all actions (whether successful or not) is 2602 attempted, and that SUPAPolicies that otherwise would have been 2603 executed are ignored. A value of 3 means that execution is stopped, 2604 and rollback is attempted for ONLY the SUPAPolicy that failed to 2605 execute correctly. A value of 4 means that execution is stopped, but 2606 no actions are rolled back. A value of 5 means that the failure is 2607 ignored, and execution continues. 2609 5.3.2. SUPAPolicyStructure Relationships 2611 The SUPAPolicyStructure class owns four relationships, which are 2612 defined in the following subsections. 2614 5.3.2.1. The Aggregation "SUPAHasPolicySource" 2616 This is an optional aggregation, and defines the set of 2617 SUPAPolicySource objects that are attached to this particular 2618 SUPAPolicyStructure object. The semantics of this aggregation 2619 are defined by the SUPAHasPolicySourceDetail association class. 2620 PolicySource objects are used for authorization policies, as well 2621 as to enforce deontic and alethic logic. 2623 The multiplicity of this aggregation is 0..n - 0..n. This means 2624 that it is an optional aggregation; zero or more SUPAPolicySource 2625 objects may be aggregated by this SUPAPolicyStructure object, 2626 and zero or more SUPAPolicyStructure objects may aggregate this 2627 particular SUPAPolicySource object. 2629 5.3.2.2. The Association Class "SUPAHasPolicySourceDetail" 2631 This is an optional concrete association class, and defines the 2632 semantics of the SUPAHasPolicySource aggregation. The attributes and 2633 relationships of this class can be used to define which 2634 SUPAPolicySource objects can be attached to which particular set 2635 of SUPAPolicyStructure objects. 2637 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" 2639 This is an optional Boolean attribute. If the value of this 2640 attribute is true, then this SUPAPolicySource object has been 2641 authenticated by this particular SUPAPolicyStructure object. 2643 5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" 2645 This is an optional Boolean attribute. If the value of this 2646 attribute is TRUE, then this particular SUPAPolicySource object 2647 has been verified to be trusted by this particular 2648 SUPAPolicyStructure object. 2650 5.3.2.3. The Aggregation "SUPAHasPolicyTarget" 2652 This is an optional aggregation, and defines the set of 2653 SUPAPolicyTargets that are attached to this particular 2654 SUPAPolicyStructure. The semantics of this aggregation is 2655 defined by the SUPAHasPolicyTargetDetail association class. The 2656 purpose of this class is to explicitly identify managed objects 2657 that will be affected by the execution of one or more SUPAPolicies. 2659 The multiplicity of this aggregation is 0..n - 0..n. This means 2660 that it is an optional aggregation; zero or more SUPAPolicyTarget 2661 objects may be aggregated by this SUPAPolicyStructure object, 2662 and zero or more SUPAPolicyStructure objects may aggregate this 2663 particular SUPAPolicyTarget object. 2665 5.3.2.4. The Association Class "SUPAHasPolicyTargetDetail" 2667 This is an optional concrete association class, and defines the 2668 semantics of the SUPAPolicyTargetOf aggregation. The attributes and 2669 relationships of this class can be used to define which 2670 SUPAPolicyTargets can be attached to which particular set of 2671 SUPAPolicyStructure objects. 2673 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" 2675 This is an optional Boolean attribute. If the value of this 2676 attribute is true, then this SUPAPolicyTarget object has been 2677 authenticated by this particular SUPAPolicyStructure object. 2679 5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" 2681 This is an optional Boolean attribute. If its value is TRUE, then 2682 this SUPAPolicyTarget is able to be used as a SUPAPolicyTarget. 2683 This means that it meets two specific criteria: 2685 1. it has agreed to play the role of a SUPAPolicyTarget (i.e., 2686 it is willing to have SUPAPolicies applied to it, and 2687 2. it is able to either process (directly or with the aid of 2688 a proxy) SUPAPolicies or receive the results of a processed 2689 SUPAPolicy and apply those results to itself. 2691 5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" 2693 This is an optional association that defines which, if any, actions 2694 should be taken if this SUPAPolicyStructure object instance fails 2695 to execute correctly. The semantics of this association are defined 2696 in the SUPAHasPolExecFailTakeActionDetail association class. 2698 For a given SUPAPolicyStructure object A, this association defines 2699 a set of policy action objects B to execute if (and only if) the 2700 SUPAPolicyStructure object A failed to execute correctly. The 2701 multiplicity of this association is defined as 0..n on the owner 2702 (A) side and 1..n on the part (B) side. This means that this 2703 association is optional; if it is instantiated, then at least one 2704 SUPAPolicyStructure MUST be instantiated by this 2705 SUPAPolicyStructure object. Similarly, one or more 2706 SUPAPolicyStructure objects may be associated with this given 2707 SUPAPolicyStructure object. 2709 5.3.2.6. The Association Class "SUPAHasPolExecFailTakeActionDetail" 2711 This is an optional concrete class that defines the semantics for 2712 the SUPAHasPolExecFailTakeAction association. The attributes and/or 2713 relationships of this association class can be used to determine 2714 which policy action objects are executed in response to a failure 2715 of the SUPAPolicyStructure object instance that owns this 2716 association. The association relates the policy actions from one 2717 SUPAPolicyStructure B to be executed if a SUPAPolicyStructure A 2718 fails to execute properly. Figure 18 illustrates this approach. 2720 A 2721 +---------------------------+ 0..n 2722 | +---------------------------------+ 2723 | | SUPAHasPolExecFailTakeAction | 2724 | SUPAPolicyStructure |/ | 2725 | + --------------+-----------------+ 2726 | |\ ^ 2727 +---------------------------+ 1..n | 2728 | 2729 C | 2730 +------------------+-----------------+ 2731 | SUPAHasPolExecFailTakeActionDetail | 2732 +------------------------------------+ 2734 Figure 18. SUPAHasPolExecFailTakeAction Association 2736 5.3.2.6.1. The Attribute "supaPolExecFailActionEncoding" 2738 This is an optional enumerated, non-negative integer attribute 2739 that defines how to find the set of SUPAPolicyActions contained 2740 in each element of the supaPolExecFailTakeActionName class 2741 attribute. Values include: 2743 0: error 2744 1: init 2745 2: URI 2746 3: GUID 2747 4: UUID 2748 5: FQDN 2749 6: FQPN 2750 7: string 2751 8: string_instance_id 2753 The values 0 and 1 represent an error state and an initialization 2754 state, respectively. Values 2-6 define a representation for the 2755 SUPAPolicyAction. A value of 7 defines an ASCII string that 2756 contains the name of the SUPAPolicyAction to be executed (e.g., to 2757 be used in a regex search). A value of 8 defines the canonical 2758 representation, in ASCII, of an instance ID of this object. 2760 5.3.2.6.2. The Attribute "supaPolExecFailActionName[1..n]" 2762 This is an optional array of string attributes that identifies the 2763 set of SUPAPolicyActions to take if the SUPAPolicyStructure object 2764 that owns this association failed to execute properly. The 2765 interpretation of this string attribute is defined by the 2766 supaPolExecFailTakeActionEncoding class attribute. The association 2767 defines the SUPAPolicyStructure that contains the set of policy 2768 actions to execute, and this attribute defines which of these 2769 actions are to be executed. That there is no need to execute a 2770 SUPAPolicy, since the event and failure have already occurred. 2771 Note: [1..n] means that this is a multi-valued property that has 2772 at least one (and possibly more) attributes. 2774 5.3.2.7. The Aggregation "SUPAHasPolicyClause" 2776 This is an optional aggregation that defines the set of 2777 SUPAPolicyClauses that are aggregated by this particular 2778 SUPAPolicyStructure instance. The semantics of this 2779 aggregation are defined by the SUPAHasPolicyClauseDetail 2780 association class. 2782 Every SUPAPolicyStructure object instance MUST aggregate at 2783 least one SUPAPolicyClause object instance. However, the 2784 converse is NOT true. For example, a SUPAPolicyClause could be 2785 instantiated and then stored for later use in a policy repository. 2786 Furthermore, the same SUPAPolicyClause could be used by zero or 2787 more SUPAPolicyStructure object instances at a given time. Thus, 2788 the multiplicity of this aggregation is defined as 0..1 on the 2789 aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the 2790 part (i.e., the SUPAPolicyClause side). This means that at 2791 least one SUPAPolicyClause MUST be aggregated by this 2792 SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may 2793 be aggregated by this particular SUPAPolicyStructure object. 2795 5.3.2.8. The Association Class "SUPAHasPolicyClauseDetail" 2797 This is an optional abstract association class, and defines the 2798 semantics of the SUPAHasPolicyClause aggregation. The attributes 2799 and/or relationships of this association class can be used to 2800 determine which SUPAPolicyClauses are aggregated by which 2801 SUPAPolicyStructure objects. 2803 Attributes will be added to this class at a later time. 2805 5.4. The Abstract Class "SUPAPolicyComponentStructure" 2807 This is a mandatory abstract class that is the superclass of all 2808 objects that represent different types of components of a 2809 SUPAPolicy. Different types of policies have different types of 2810 structural components. This is accommodated by defining two generic 2811 subclasses, called SUPAPolicyClause and SUPAPolicyComponentDecorator, 2812 which are common to different policy types. These two classes 2813 represent convenient control points for defining characteristics 2814 and behavior that are common to objects that serve as components of 2815 a SUPAPolicy. 2817 SUPAPolicyClause defines a basic building block for writing 2818 parts of a SUPAPolicy. It is analogous to a clause in a sentence. 2819 For example, in an ECA Policy Rule, the Event, Condition, and Action 2820 clauses are each made up of at least one (subclass of a) 2821 SUPAPolicyClause. Similalry, declarative Policy Rules can also be 2822 defined using (its own subclasses of) SUPAPolicyClauses. This class 2823 is defined in section 5.5. 2825 SUPAPolicyComponentDecorator is used to implement the decorator 2826 pattern [11]. The decorator pattern enables all or part of one or 2827 more objects to "wrap" another concrete object. This enables the 2828 definition of an extensible set of subclasses that can augment the 2829 definition of a SUPAPolicyClause. This class is defined in 2830 section 5.7. 2832 Note that there are significant differences between the definition 2833 of the SUPAPolicyComponentStructure class, and its attributes and 2834 relationships, and the definition of the corresponding class (and 2835 its attributes and relationships) in [5]. 2837 5.4.1. SUPAPolicyComponentStructure Attributes 2839 No attributes are currently defined for the 2840 SUPAPolicyComponentStructure class. 2842 5.4.2. SUPAPolicyComponentStructure Relationships 2844 SUPAPolicyComponentStructure participates in a single relationship, 2845 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 2847 5.5. The Abstract Class "SUPAPolicyClause" 2849 This is a mandatory abstract class that separates the 2850 representation of a SUPAPolicy from its implementation. 2851 SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction 2852 is missing in [RFC3060], [RFC3460], [4], and [6]. This class is 2853 called PolicyStatement in [5], but the class and relationship 2854 definitions differ significantly from the corresponding designs 2855 in this document. 2857 A SUPAPolicy, regardless of its structure and semantics, can be 2858 abstracted into a set of sentences. Each sentence can in turn be 2859 abstracted into a set of clauses. A SUPAPolicyClause is, as its 2860 name implies, a clause (i.e., a part of a statement), and defines 2861 the content of a SUPAPolicy. The decorator pattern is used to 2862 enable an extensible set of objects to "wrap" the SUPAPolicyClause; 2863 this enables the contents of a SUPAPolicyClause to be adjusted 2864 dynamically at runtime without affecting other objects. 2866 This document defines two different types of policy clauses: 2867 SUPAEncodedClause (which is generic, and can be used by any 2868 type of policy), and SUPABooleanClause (which is also generic, 2869 but is typically used by SUPAECAPolicyRule objects, since it is 2870 used specifically to represent Boolean clauses). 2872 SUPAPolicyClauses are objects in their own right, which 2873 facilitates their reuse. SUPAPolicyClauses can aggregate a set 2874 of any of the subclasses of SUPAPolicyComponentDecorator, which 2875 was shown in Figure 10. These four subclasses (i.e., SUPAPolicyTerm, 2876 SUPAGenericDecoratedComponent, SUPAECAComponent, and SUPACollection) 2877 provide four different ways to construct a SUPAPolicyClause: 2879 1) a SUPAPolicyClause can be made up of a set of three 2880 SUPAPolicyTerms, which enables constructing a {variable, 2881 operator, value} expression for building SUPAPolicyClauses 2882 2) a SUPAPolicyClause can be made up of one or more 2883 SUPAEncodedClauses, which enables a SUPAPolicyClause to be 2884 formed as an encoded object (e.g., to pass YANG or CLI code) 2885 3) a SUPAPolicyClause can be made up of a set of SUPACollections, 2886 which define a Collection (e.g., set, bad, associative arrays) 2887 of objects that can be assembled into SUPAPolicyClauses 2888 4) a SUPAPolicyClause can be made up of one or more 2889 SUPAECAComponents, which enables a SUPAPolicyClause to be 2890 formed using (reusable) Event, Condition, and/or Action 2891 objects 2893 SUPAPolicyClauses are aggregated by a SUPAPolicyStructure 2894 object, which enables all types of SUPAPolicies to uniformly be 2895 made up of one or more SUPAPolicyClauses. 2897 5.5.1. SUPAPolicyClause Attributes 2899 This section defines the attributes of the SUPAPolicyClause 2900 class, which are inherited by all SUPAPolicyClause subclasses. 2902 5.5.1.1. The Attribute "supaPolClauseDeployStatus" 2904 This is an optional enumerated, non-negative integer attribute. The 2905 purpose of this attribute is to indicate that this SUPAPolicyClause 2906 can or cannot be deployed by the policy management system. This 2907 attribute enables the policy manager to know which SUPAPolicyClauses 2908 to retrieve, and may be useful for the policy execution system for 2909 planning the staging of SUPAPolicies. Values include: 2911 0: error 2912 1: init 2913 2: deployed and enabled 2914 3: deployed and in test 2915 4: deployed but not enabled 2916 5: ready to be deployed 2917 6: cannot be deployed 2919 The values 0 and 1 represent an error state and an initialization 2920 state, respectively. If the value of this attribute is 0 or 6, then 2921 the policy management system SHOULD ignore this SUPAPolicy. 2922 Otherwise, the policy management system MAY use this SUPAPolicyClause 2923 (once this SUPAPolicyClause is deployed and enabled). However, a 2924 value of 4 means that this policy is not admininstratively enabled 2925 for use and SHOULD NOT be used in OAM&P policies. 2927 5.5.2. SUPAPolicyClause Relationships 2929 SUPAPolicyClause participates in a single relationship, 2930 SUPAHasPolicyClause, as defined in section 5.3.2.7. Note that 2931 SUPAPolicyClause uses the decorator pattern to "wrap" this object 2932 with instances of the (concrete) subclasses of the 2933 SUPAPolicyComponentDecorator object. 2935 5.6. The Concrete Class "SUPAEncodedClause" 2937 This is a mandatory concrete class that refines the behavior of a 2938 SUPAPolicyClause. 2940 This class defines a generalized extension mechanism for 2941 representing SUPAPolicyClauses that have not been modeled 2942 with other SUPAPolicy objects. Rather, the contents of the policy 2943 clause are directly encoded into the attributes of the 2944 SUPAEncodedClause. Hence, SUPAEncodedClause objects are reusable 2945 at the object level, whereas SUPABooleanClause clauses are reusable 2946 at the individual Boolean expression level. 2948 This class uses two of its attributes (supaEncodedClauseContent and 2949 supaEncodedClauseEncoding) for defining the content and type of 2950 encoding used in a given SUPAPolicyClause. The benefit of a 2951 SUPAEncodedClause is that it enables direct encoding of the text of 2952 the SUPAPolicyClause, without having the "overhead" of using other 2953 objects. However, note that while this method is efficient, it 2954 does not reuse other SUPAPolicy objects. Furthermore, its potentially 2955 for reuse is reduced, as only SUPAPolicies that can use the exact 2956 encoding of this clause can reuse this object. 2958 5.6.1. SUPAEncodedClause Attributes 2960 This section defines the attributes of the SUPAEncodedClause class. 2961 Prescriptive and/or descriptive information about the usage of this 2962 SUPAEncodedClause may be provided by one or more SUPAPolicyMetadata 2963 objects, which are each attached to the object instance of this 2964 SUPAEncodedClause. 2966 5.6.1.1. The Attribute "supaEncodedClauseContent" 2968 This is a mandatory string attribute, and defines the content of 2969 this clause. It works with another class attribute, called 2970 supaEncodedClauseEncoding, which defines how to interpret the 2971 value of this attribute (e.g., as a string or reference). These 2972 two attributes form a tuple, and together enable a machine to 2973 understand the syntax and value of this object instance. 2975 5.6.1.2. The Attribute "supaEncodedClauseEncoding" 2977 This is a mandatory non-negative integer attribute, and defines 2978 how to interpret the value of the supaEncodedClauseContent. It 2979 works with another class attribute (supaEncodedClauseContent), 2980 which defines the content of the encoded clause. These two 2981 attributes form a tuple, and together enable a machine to 2982 understand the syntax and value of the encoded clause for the 2983 object instance of this class. This attribute is NOT required in 2984 all data model implementations. Values include: 2986 0: error (i.e., an error state) 2987 1: init (i.e., an initialization state) 2988 2: primary_key 2989 3: foreign_key 2990 4: GUID 2991 5: UUID 2992 6: URI 2993 7: FQDN 2994 8: FQPN 2995 9: string_instance_id 2997 The values 0 and 1 represent an error state and an initialization 2998 state, respectively. The value 9 defines the canonical 2999 representation, in ASCII, of an instance ID of this object. 3001 5.6.1.3. The Attribute "supaEncodedClauseLanguage" 3003 This is mandatory non-negative integer attribute, and defines 3004 the type of language used in this encoded clause. Values include: 3006 0: error 3007 1: init 3008 2: Text 3009 3: YANG 3010 4: XML 3011 5: TL1 3013 The values 0 and 1 represent an error state and an initialization 3014 state, respectively. 3016 5.6.1.4. The Attribute "supaEncodedClauseResponse" 3018 This is an optional Boolean attribute that emulates a Boolean 3019 response of this clause, so that it may be combined with other 3020 subclasses of the SUPAPolicyClause that provide a status as to 3021 their correctness and/or evaluation state. This enables this 3022 object to be used to construct more complex Boolean clauses. 3023 Note that this attribute does NOT have to be implemented by all 3024 data model implementations (e.g., [15]). 3026 5.6.2. SUPAEncodedClause Relationships 3028 SUPAPolicyClause participates in a single inherited relationship, 3029 SUPAHasPolicyClause, as defined in section 5.3.2.7. 3031 5.7. The Abstract Class "SUPAPolicyComponentDecorator" 3033 This is a mandatory class, and is used to implement the decorator 3034 pattern. The decorator pattern enables all or part of one or more 3035 objects to "wrap" another concrete object. This means that any 3036 any concrete subclass of SUPAPolicyClause is wrapped by any 3037 concrete subclass of SUPAPolicyComponentDecorator, as shown in 3038 Figure 19 below. 3040 A 3041 +------------------------------+ 3042 | | 1..n 3043 | SUPAPolicyComponentStructure +--------+ 3044 | | | used to wrap 3045 +------------------------------+ | concrete 3046 / \ | subclasses of 3047 I | PolicyClause 3048 I | 3049 +---------------+--------------+ / \ 3050 I I A 3051 A I A I \ / 0..1 3052 +----------+---------+ +--------------+-----+---------+ 3053 | SUPAPolicyClause | | SUPAPolicyComponentDecorator | 3054 +----------+---------+ +--------------+---------------+ 3055 I I 3056 I I 3057 / \ / \ 3058 Concrete Subclasses, Concrete Subclasses 3059 (e.g., SUPAEncodedClause) (e.g., SUPAPolicyEvent) 3060 (object being wrapped) (wrapping object(s)) 3062 Figure 19. The PolicyComponent Decorator Pattern 3064 5.7.1. The Decorator Pattern 3066 Each SUPAPolicyComponentDecorator object HAS_A (i.e., wraps) a 3067 concrete instance of the SUPAPolicyClause object. This means that 3068 the SUPAPolicyComponentDecorator object has an instance variable 3069 that holds a reference to a SUPAPolicyClause object. Since the 3070 SUPAPolicyComponentDecorator object has the same interface as the 3071 SUPAPolicyClause object, the SUPAPolicyComponentDecorator object 3072 (and all of its subclasses) are transparent to clients of the 3073 SUPAPolicyClause object (and its subclasses). This means that 3074 SUPAPolicyComponentDecorator object instances can add attributes 3075 and/or methods to those of the concrete instance of the chosen 3076 subclass of SUPAPolicyClause. 3078 Figure 20 shows how this is done for methods. 3079 - Figure 20a shows the initial object to be wrapped 3080 - Figure 20b shows the SUPAPolicyEvent object wrapping the 3081 SUPAEncodedClause object 3082 - Figure 20c shows SUPAGenericDecoratedComponent object 3083 wrapping the SUPAPolicyEvent object. 3085 +-------------------+ 3086 | SUPAEncodedClause | 3087 | eval() | 3088 +-------------------+ 3089 (a) Initial Object 3091 ===> 3092 +------------------------+ 3093 | SUPAPolicyEvent | 3094 | eval() | 3095 | +-------------------+ | 3096 | | SUPAEncodedClause | | 3097 | | eval() | | 3098 | +-------------------+ | 3099 +------------------------+ 3100 (b) SUPAPolicyEvent "wraps" SUPAEncodedClause 3102 ===> 3103 +--------------------------------+ 3104 | SUPAGenericDecoratedComponent | 3105 | eval() | 3106 | +-----------------------+ | 3107 | | SUPAPolicyEvent | | 3108 | | eval() | | 3109 | | +-------------------+ | | 3110 | | | SUPAEncodedClause | | | 3111 | | | eval() | | | 3112 | | +-------------------+ | | 3113 | +-----------------------+ | 3114 +--------------------------------+ 3115 (c) SUPAGenericDecoratedComponent "wraps" SUPAPolicyEvent 3117 Figure 20. Conceptual Depiction of eval() Decorated Method 3119 When the eval() method is called in the outermost object 3120 (SUPAGenericDecoratedComponent), it delegates to the eval() method 3121 of SUPAPolicyEvent, which in turn delegates to the eval() method 3122 of SUPAEncodedClause. This method executes and returns the 3123 results to SUPAPolicyEvent, which executes and returns the results 3124 to SUPAGenericDecoratedComponent, which executes and returns the 3125 final result. 3127 5.7.2. SUPAPolicyComponentDecorator Attributes 3129 Currently, there are two attributes defined for this class, which 3130 are described in the following subsections. Both attributes are 3131 used by subclasses to constrain the behavior of that subclass; 3132 they do **not** affect the relationship between the concrete 3133 subclass of SUPAPolicyComponentDecorator that is wrapping the 3134 concrete subclass of SUPAPolicyClause. 3136 This is different than the use of similar attributes defined in 3137 the SUPAHasDecoratedPolicyComponentDetail association class (which 3138 are used to constrain the relationship between the concrete 3139 subclass of SUPAPolicyClause and the concrete subclass of the 3140 SUPAPolicyComponentDecorator object that is wrapping it). 3141 Note that [2] does not define any attributes for this class. 3143 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" 3145 This is a mandatory non-negative enumerated integer that defines 3146 how to interpret each string in the supaPolCompConstraint class 3147 attribute. Values include: 3149 0: error 3150 1: init 3151 2: OCL 2.4 3152 3: OCL 2.x 3153 4: OCL 1.x 3154 5: QVT 1.2 - Relations Language 3155 6: QVT 1.2 - Operational language 3156 7: Alloy 3157 8: ASCII Text 3159 Enumerations 1 and 2 signify an error state and an initialization 3160 state, respectively. Enumeraitons 3-5 are dedicated to OCL (with 3161 OCL 2.4 being the latest version as of this writing). QVT defines a 3162 set of languages [20] (the two most powerful and useful are defined 3163 by enumerations 5 and 6). Alloy is a language for describing 3164 constraints, and uses a SAT solver to guarantee correctness [21]. 3165 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 3166 and hence, not verifiable), but is included for completeness. 3168 If this class is instantiated, then this attribute SHOULD also be 3169 instantiated, and SHOULD be part of a conformant implementation. 3171 5.7.2.2. The Attribute "supaPolCompConstraint[0..n]" 3173 This is a mandatory array of string attributes. Each attribute 3174 specifies a constraint to be applied using the encoding defined in 3175 the supaPolCompConstraintEncoding class attribute. This provides 3176 a more rigorous and flexible treatment of constraints than is 3177 possible in [RFC3460], [4], [5], and [6]. 3179 Note: [0..n] means that this is a multi-valued property that may 3180 have zero or more attributes. 3182 5.7.3. SUPAPolicyComponentDecorator Relationships 3184 One relationship is currently defined for this class, which is 3185 described in the following subsection. 3187 5.7.3.1. The Aggregation "SUPAHasDecoratedPolicyComponent" 3189 This is a mandatory aggregation, and is part of a decorator 3190 pattern. It is used to enable a concrete instance of a 3191 SUPAPolicyComponentDecorator to dynamically add behavior to a 3192 specific type of SUPAPolicyClause object. The semantics of this 3193 aggregation are defined by the 3194 SUPAHasDecoratedPolicyComponentDetail association class. 3196 5.7.3.2. The Association Class 3197 "SUPAHasDecoratedPolicyComponentDetail" 3199 This is a mandatory concrete association class, and defines the 3200 semantics of the SUPAHasDecoratedPolicyComponent aggregation. The 3201 purpose of this class is to use the Decorator pattern to determine 3202 which SUPAPolicyComponentDecorator object instances, if any, are 3203 required to augment the functionality of the concrete subclass of 3204 SUPAPolicyClause that is being used. 3206 Currently, there are two attributes defined for this class, which 3207 are described in the following subsections. Both attributes are 3208 used in this association class to constrain the **relationship** 3209 between the concrete subclass of SUPAPolicyComponentDecorator that 3210 is wrapping the concrete subclass of SUPAPolicyClause. Note that 3211 class attributes of SUPAPolicyComponentDecorator (see section 3212 5.9.2) only affect that specific subclass. 3214 5.7.3.2.1. The Attribute "supaDecoratedConstraintEncoding" 3216 This is a mandatory non-negative enumerated integer that defines 3217 how to interpret each string in the supaDecoratedConstraint class 3218 attribute. Values include: 3220 0: error 3221 1: init 3222 2: OCL 2.4 3223 3: OCL 2.x 3224 4: OCL 1.x 3225 5: QVT 1.2 - Relations Language 3226 6: QVT 1.2 - Operational language 3227 7: Alloy 3228 8: ASCII Text 3230 Enumerations 1 and 2 signify an error state and an initialization 3231 state, respectively. Enumeraitons 3-5 are dedicated to OCL (with 3232 OCL 2.4 being the latest version as of this writing). QVT defines a 3233 set of languages [20] (the two most powerful and useful are defined 3234 by enumerations 5 and 6). Alloy is a language for describing 3235 constraints, and uses a SAT solver to guarantee correctness [21]. 3236 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 3237 and hence, not verifiable), but is included for completeness. 3239 If this class is instantiated, then this attribute SHOULD also be 3240 instantiated, and SHOULD be part of a conformant implementation. 3242 5.7.3.2.2. The Attribute "supaDecoratedConstraint[0..n]" 3244 This is a mandatory array of string attributes. Its purpose is to 3245 collect a set of constraints to be applied to a decorated object. 3246 The interpretation of each constraint in the array is defined in 3247 the supaDecoratedConstraintsEncoding class attribute. 3248 Note: [0..n] means that this is a multi-valued property that may 3249 have zero or more attributes. 3251 5.7.4. Illustration of Constraints in the Decorator Pattern 3253 Figure 21 builds a simple SUPAPolicyClause that has both types 3254 of relationships, and illustrates how the different constraints 3255 defined in sections 5.7.2 (class attribute constraints) and section 3256 5.7.3 (relationship constraints) can be used. 3258 A A 3259 +------------------+ 0..1 +----------------------------+ 3260 | | 1..n / \| | 3261 | SUPAPolicyClause +------+----- A +SUPAPolicyComponentDecorator| 3262 | | ^ \ /| | 3263 +---------+--------+ | +-----------+----------------+ 3264 I | I 3265 I | I 3266 C I | C I 3267 +--------+--------+ | +---------+---------+ 3268 |SUPAEncodedClause| | | SUPAPolicyEvent | 3269 +-----------------+ | +-------------------+ 3270 | 3271 C | 3272 +-----------------+-------------------+ 3273 |SUPAHasDecoratedPolicyComponentDetail| 3274 +-------------------------------------+ 3276 Figure 21. Constraints in the Decorator Pattern 3278 Figure 21 says that a SUPAPolicyClause, realized as a 3279 SUPAEncodedClause, is wrapped by a SUPAPolicyEvent object. The 3280 attributes in the SUPAPolicyComponentDecorator object are used 3281 to constrain the attributes in the SUPAPolicyEvent object, while 3282 the attributes in the SUPAHasDecoratedPolicyComponentDetail 3283 object are used to contrain the behavior of the aggregation 3284 (SUPAHasDecoratedPolicyComponent). For example, the attributes in 3285 the SUPAPolicyComponentDecorator object could restrict the data 3286 type and range of the components in the SUPAPolicyEvent, while 3287 the attributes in the SUPAHasDecoratedPolicyComponentDetail object 3288 could restrict which SUPAPolicyEvent objects are allowed to be 3289 used with which SUPAEncodedClauses. 3291 5.8. The Abstract Class "SUPAPolicyTerm" 3293 This is a mandatory abstract class that is the parent of 3294 SUPAPolicy objects that can be used to define a standard way to 3295 test or set the value of a variable. It does this by defining a 3296 3-tuple, in the form {variable, operator, value}, where each 3297 element of the 3-tuple is defined by a concrete subclass of the 3298 appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator, 3299 and SUPAPolicyValue classes, respectively). For example, a 3300 generic test or set of the value of a variable is expressed as: 3302 {variable, operator, value}. 3304 For event and condition clauses, this is typically as written above 3305 (e.g., does variable = value); for action clauses, it is typically 3306 written as (e.g., SET var to 1). A 3307 class diagram is shown in Figure 22. 3309 A 3310 +----------------+ 3311 | SUPAPolicyTerm | 3312 +--------+-------+ 3313 / \ 3314 I 3315 I 3316 I 3317 +-----------------+---+--------------------+ 3318 I I I 3319 I I I 3320 C I C I C I 3321 +--------+---------+ +--------+---------+ +-------+-------+ 3322 |SUPAPolicyVariable| |SUPAPolicyOperator| |SUPAPolicyValue| 3323 +------------------+ +------------------+ +---------------+ 3325 Figure 22. SUPAPolicyTerm Class Hierarchy 3327 Note that generic test and set expressions do not have to only use 3328 objects that are subclasses of SUPAPolicyTerm. For example, the 3329 polVendorDecoratedContent attribute of the 3330 SUPAGenericDecoratedComponent could be used as the variable (or the 3331 value) term of a get or set expression. 3333 Hence, the utility of the subclasses of SUPAPolicyTerm is in the 3334 ability of its subclasses to define a generic framework for 3335 implementing get and set expressions. This is in contrast to 3336 previous designs (e.g., [RFC3460] and [6]), which depended on 3337 defining a broad set of subclasses of PolicyVariable and 3338 PolicyValue. (Note that [4] does not have this generic capability). 3340 5.8.1. SUPAPolicyTerm Attributes 3342 Currently, SUPAPolicyTerm defines a single attribute, as described 3343 in the following subsection. Constraints on the subclasses of 3344 SUPAPolicyTerm can be applied in two different ways: 3346 1. use SUPAPolicyComponentDecorator attributes to constrain 3347 just that individual subclass, and/or 3348 2. use SUPAHasDecoratedPolicyComponentDetail association class 3349 attributes to constrain the relationship between the concrete 3350 subclass of SUPAPolicyClause and the concrete subclass of 3351 the SUPAPolicyTerm class 3353 5.8.1.1. The Attribute "supaPolTermIsNegated" 3355 This is a mandatory Boolean attribute. If the value of this 3356 attribute is true, then this particular SUPAPolicyTerm subclass 3357 (which represents a term) is negated; otherwise, it is not. 3359 5.8.2. SUPAPolicyTerm Relationships 3361 Currently, no dedicated relationships are defined for the 3362 SUPAPolicyTerm class (as there are in [RFC3460] and [6]) that 3363 aggregate policy variable and policy value objects into a policy 3364 rule). This is: 3366 1) to enable the subclasses of SUPAPolicyTerm to be used by 3367 other SUPAPolicyComponentDecorator objects, and 3368 2) because the decorator pattern replaces how such relationships 3369 were used in [RFC3460] and [6]. 3371 SUPAPolicyTerm, and its subclasses, inherit the 3372 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3373 section 5.7.3. 3375 5.9. The Concrete Class "SUPAPolicyVariable" 3377 This is a mandatory concrete class that defines information that 3378 forms a part of a SUPAPolicyClause. It specifies a concept or 3379 attribute that represents a variable, which should be compared to 3380 a value, as specifed in this SUPAPolicyClause. If it is used in 3381 a SUPAECAPolicyRule, then its value MAY be able to be changed at 3382 any time, including run-time, via use of the decorator pattern. 3383 This is not possible in previous designs ([RFC3460, [4], and [6]). 3385 The value of a SUPAPolicyVariable is typically compared to the 3386 value of a SUPAPolicyValue using the type of operator defined in 3387 a SUPAPolicyOperator. However, other objects may be used instead 3388 of a SUPAPolicyValue object, and other operators may be defined 3389 in addition to those defined in the SUPAPolicyOperator class. 3391 SUPAPolicyVariables are used to abstract the representation of a 3392 SUPAPolicyRule from its implementation. Some SUPAPolicyVariables 3393 are restricted in the values and/or the data type that they may 3394 be assigned. For example, port numbers cannot be negative, and 3395 they cannot be floating-point numbers. These and other constraints 3396 may be defined in two different ways: 3398 1. use SUPAPolicyComponentDecorator attributes to constrain 3399 just that individual subclass, and/or 3400 2. use SUPAHasDecoratedPolicyComponentDetail association class 3401 attributes to constrain the relationship between the concrete 3402 subclass of SUPAPolicyClause and the concrete subclass of 3403 the SUPAPolicyVariable class 3405 Please refer to the examples in section 7, which show how to 3406 restrict the value, data type, range, and other semantics of the 3407 SUPAPolicyVariable when used in a SUPAPolicyClause. 3409 5.9.1. Problems with the RFC3460 Version of PolicyValue 3411 Please see Appendix A for a detailed comparison. 3413 5.9.2. SUPAPolicyVariable Attributes 3415 SUPAPolicyVariable defines one attribute, as described below. 3417 5.9.2.1. The Attribute "supaPolVarName" 3419 This is an optional string attribute that contains the name of 3420 this SUPAPolicyVariable. This variable name forms part of the 3421 {variable, operator, value} canonical form of a SUPAPolicyClause. 3423 5.9.3. SUPAPolicyVariable Relationships 3425 Currently, no relationships are defined for the SUPAPolicyVariable 3426 class (note that the decorator pattern obviates the need for 3427 relationships such as those defined in [RFC3460] and [6]). This is 3428 because SUPAPolicyVariable, and its subclasses, inherit the 3429 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3430 section 5.7.3. 3432 5.10. The Concrete Class "SUPAPolicyOperator" 3434 This is a mandatory concrete class for modeling different types of 3435 operators that are used in a SUPAPolicyClause. 3437 The restriction of the type of operator used in a SUPAPolicyClause 3438 restricts the semantics that can be expressed in that 3439 SUPAPolicyClause. It is typically used with SUPAPolicyVariables 3440 and SUPAPolicyValue to form a SUPAPolicyClause. 3442 5.10.1. Problems with the RFC3460 Version 3444 Please see Appendix A for a detailed comparison. 3446 5.10.2. SUPAPolicyOperator Attributes 3448 Currently, SUPAPolicyOperator defines a single generic attribute, 3449 as described below. 3451 5.10.2.1. The Attribute "supaPolOpType" 3453 This is a mandatory non-negative enumerated integer that specifies 3454 the various types of operators that are allowed to be used in this 3455 particular SUPAPolicyClause. Values include: 3457 0: error 3458 1: init 3459 2: Greater than 3460 3: Greater than or equal to 3461 4: Less than 3462 5: Less than or equal to 3463 6: Equal to 3464 7: Not equal to 3465 8: IN 3466 9: NOT IN 3467 10: SET 3468 11: CLEAR (0 for integers, "" for strings, FALSE for Booleans) 3469 12: BETWEEN (inclusive) 3471 Note that 0 and 1 represent error and initialization states, 3472 respectively. Their purpose is to support dynamically building a 3473 SUPAPolicyClause by enabling the application to set the value of 3474 this attribute to a standard value. 3476 Additional operators may be defined in future work. For example, 3477 if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from 3478 include structured objects, then "deep" versions of operators 3479 1-6 could also be defined. In this case, values 1-6 will be 3480 edited to explicitly indicate that they perform "shallow" 3481 comparison operations. 3483 5.10.3. SUPAPolicyOperator Relationships 3485 Currently, no relationships are defined for the SUPAPolicyOperator 3486 class (note that the decorator pattern obviates the need for 3487 relationships such as those in [6]). This is because 3488 SUPAPolicyOperator, and its subclasses, inherit the 3489 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3490 section 5.7.3. Please refer to the examples in section 7, which 3491 show how to restrict the value, data type, range, and other 3492 semantics of the SUPAPolicyOperator when used in a SUPAPolicyClause. 3494 5.11. The Concrete Class "SUPAPolicyValue" 3496 The SUPAPolicyValue class is a mandatory concrete class for 3497 modeling different types of values and constants that occur in a 3498 SUPAPolicyClause. 3500 SUPAPolicyValues are used to abstract the representation of a 3501 SUPAPolicyRule from its implementation. Therefore, the design of 3502 SUPAPolicyValues depends on two important factors. First, just as 3503 with SUPAPolicyVariables (see Section 5.11), some types of 3504 SUPAPolicyValues are restricted in the values and/or the data 3505 type that they may be assigned. Second, there is a high likelihood 3506 that specific applications will need to use their own variables 3507 that have specific meaning to a particular application. 3509 In general, there are two ways to apply constraints to an object 3510 instance of a SUPAPolicyValue: 3512 1. use SUPAPolicyComponentDecorator attributes to constrain 3513 just that individual subclass, and/or 3514 2. use SUPAHasDecoratedPolicyComponentDetail association class 3515 attributes to constrain the relationship between the concrete 3516 subclass of SUPAPolicyClause and the concrete subclass of 3517 the SUPAPolicyValue class 3519 The value of a SUPAPolicyValue is typically compared to the value 3520 of a SUPAPolicyVariable using the type of operator defined in 3521 a SUPAPolicyOperator. However, other objects may be used instead 3522 of a SUPAPolicyVariable object, and other operators may be defined 3523 in addition to those defined in the SUPAPolicyOperator class. 3525 5.11.1. Problems with the RFC3460 Version of PolicyValue 3527 Please see Appendix A for a detailed comparison. 3529 5.11.2. SUPAPolicyValue Attributes 3531 Currently, SUPAPolicyValue defines two generic attributes, as 3532 described below. 3534 5.11.2.1. The Attribute "supaPolValContent[0..n]" 3536 This is a mandatory attribute that defines an array of strings. 3537 The array contains the value(s) of this SUPAPolicyValue object 3538 instance. Its data type is defined by the supaPolValEncoding 3539 class attribute. 3540 Note: [0..n] means that this is a multi-valued property that has 3541 zero or more attributes. 3543 5.11.2.2. The Attribute "supaPolValEncoding" 3545 This is a mandatory string attribute that contains the data type 3546 of the SUPAPolicyValue object instance. Its value is defined by 3547 the supaPolValContent class attribute. Values include: 3549 0: error 3550 1: init 3551 2: String 3552 3: Integer 3553 4: Boolean 3554 5: Floating Point 3555 6: DateTime 3556 7: GUID 3557 8: UUID 3558 9: URI 3559 10: DN 3560 11: FQDN 3561 12: FQPN 3562 13: NULL 3564 Note that 0 and 1 represent error and initialization states, 3565 respectively. A string is a sequence of zero or more characters. An 3566 Integer is a whole number, and has no fractional part. A Boolean may 3567 take the values TRUE and FALSE. A floating point number may contain 3568 fractional values, as well as an exponent. A DateTime represents a 3569 value that has a date and/or a time component (as in the Java or 3570 Python libraries). A NULL explicitly models the lack of a value. 3572 5.11.3. SUPAPolicyValue Relationships 3574 Currently, no relationships are defined for the SUPAPolicyValue 3575 class (note that the decorator pattern obviates the need for 3576 relationships such as those in [6]). SUPAPolicyValue, and its 3577 subclasses, inherit the SUPAHasDecoratedPolicyComponent 3578 aggregation, which was defined in section 5.7.3. Please refer to 3579 the examples in section 7, which show how to restrict the value, 3580 data type, range, and other semantics of the SUPAPolicyValue when 3581 used in a SUPAPolicyClause. 3583 5.12. The Concrete Class "SUPAGenericDecoratedComponent" 3585 A SUPAGenericDecoratedComponent enables a generic object to be 3586 defined and used in a SUPAPolicyClause. This class was derived 3587 from [2], but is not present in [RFC3460], [4], [5], or [6]. 3589 This class should not be confused with the SUPAEncodedClause class. 3590 The SUPAGenericDecoratedComponent class represents a single, atomic 3591 object that defines a **portion** of a SUPAPolicyClause, whereas a 3592 SUPAEncodedClause represents an **entire** SUPAPolicyClause. 3594 5.12.1. SUPAGenericDecoratedComponent Attributes 3596 Currently, SUPAGenericDecoratedComponent defines two generic 3597 attributes, as described below. 3599 5.12.1.1. The Attribute "supaVendorDecoratedCompContent[0..n]" 3601 This is a mandatory attribute that defines an array of strings. 3602 This array contains the value(s) of the 3603 SUPAGenericDecoratedComponent object instance. Its data type is 3604 defined by the supaVendorDecoratedEncoding class attribute. 3605 Note: [0..n] means that this is a multi-valued property that has 3606 zero or more attributes. 3608 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 3610 This is a mandatory integer attribute that defines the format of 3611 the supaVendorDecoratedContent class attribute. Values include: 3613 0: undefined 3614 1: String 3615 2: Integer 3616 3: Boolean 3617 4: Floating Point 3618 5: DateTime 3619 6: GUID 3620 7: UUID 3621 8: URI 3622 9: FQDN 3623 10: FQPN 3624 11: NULL 3626 Note that 0 and 1 represent error and initialization states, 3627 respectively. A string is a sequence of zero or more characters. An 3628 Integer is a whole number (e.g., it has no fractional part). A 3629 Boolean represents the values TRUE and FALSE. A floating point 3630 number may contain fractional values, as well as an exponent. A 3631 DateTime represents a value that has a date and/or a time component 3632 (as in the Java or Python libraries). A NULL explicitly models the 3633 lack of a value. 3635 5.12.2. SUPAGenericDecoratedComponent Relationships 3637 Currently, no relationships are defiend for the 3638 SUPAGenericDecoratedComponent class (note that the decorator 3639 pattern obviates the need for relationships such as those in [6]). 3640 SUPAGenericDecoratedComponent participates in a single relationship, 3641 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 3643 ** This class is under discussion - please comment as to its utility ** 3645 5.13. The Concrete Class "SUPAPolicyCollection" 3647 A SUPAPolicyCollection is an optional concrete class that enables 3648 a collection (e.g., set, bag, or other, more complex, collections 3649 of elements) of **arbitrary objects** to be defined and used as 3650 part of a SUPAPolicyClause. This class was derived from [2], but 3651 is not present in [RFC3460], [4], [5], or [6]. 3653 5.13.1. Motivation 3655 One of the problems with ECA policy rules is when a set of events 3656 or conditions needs to be tested. For example, if a set of events 3657 is received, the policy system may need to wait for patterns of 3658 events to emerge (e.g., any number of Events of type A, followed 3659 by either one event of type B or two events of type Event C). 3660 Similarly, for conditions, testing the value of a set of attributes 3661 may need to be performed. Both of these represent behavior 3662 similar to a set of if-then-else statements or a switch statement. 3664 It is typically not desirable for the policy system to represent 3665 each choice in such clauses as its own policy clause (i.e., a 3666 3-tuple), as this creates object explosion and poor performance. 3667 Furthermore, in these cases, it is often required to have a set of 3668 complex logic to be executed, where the logic varies according to 3669 the particular event or condition that was selected. It is much 3670 too complex to represent this using separate objects, especially 3671 when the logic is application- and/or vendor-specific. However, 3672 recall that one of the goals of this document was to facilitate 3673 the machine-driven construction of policies. Therefore, a solution 3674 to this problem is needed. 3676 5.13.2. Solution 3678 Therefore, this document defines the concept of a collection of 3679 entities, called a SUPAPolicyCollection. Conceptually, the items 3680 to be collected (e.g., events or conditions) are aggregated in 3681 one or more SUPAPolicyCollection objects of the appropriate type. 3682 Another optional SUPAPolicyCollection object could be used to 3683 aggregate logic blocks (including SUPAPolicies) to execute. 3684 Once finished, all appropriate SUPAPolicyCollection objects are 3685 sent to an external system for evaluation. 3687 The computation(s) represented by the SUPAPolicyCollection may be 3688 part of a larger SUPAPolicyClause, since SUPAPolicyCollection is a 3689 subclass of SUPAPolicyComponentDecorator, and can be used to 3690 decorate a SUPAPolicyClause. Therefore, the external system is 3691 responsible for providing a Boolean TRUE or FALSE return value, so 3692 that the policy system can use that value to represent the 3693 computation of the function(s) performed in the 3694 SUPAPolicyCollection in a Boolean clause. 3696 5.13.3. SUPAPolicyCollection Attributes 3698 Currently, SUPAGenericDecoratedComponent defines five attributes, 3699 as described below. 3701 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 3703 This is an optional attribute that defines an array of strings. 3704 Each string in the array identifies a domain-suitable identifier of 3705 an object that is collected by this SUPAPolicyCollection instance. 3706 Note: [0..n] means that this is a multi-valued property that has 3707 zero or more attributes. 3709 5.13.3.2. The Attribute "supaPolCollectionEncoding" 3711 This is an optional non-negative enumerated integer that defines 3712 the data type of the content of this collection instance. Values 3713 include: 3715 0: error 3716 1: init 3717 2: by regex (regular expression) 3718 3: by URI 3720 Note that 0 and 1 represent error and initialization states, 3721 respectively. If the value of this attribute is 2, then each of the 3722 strings in the supaPolCollectionContent attribute represent a regex 3723 that contains all or part of a string to match the class name of the 3724 object that is to be collected by this instance of a 3725 SUPAPolicyCollection class. If the value of this attribute is 3, 3726 then each of the strings in the supaPolCollectionContent attribute 3727 represent a URI. 3729 5.13.3.3. The Attribute "supaPolCollectionFunction" 3731 This is an optional non-negative enumerated integer that defines 3732 the function of this collection instance. Values include: 3734 0: error 3735 1: init 3736 2: event collection 3737 3: condition collection 3738 4: action collection 3739 5: logic collection 3741 Note that 0 and 1 represent error and initialization states, 3742 respectively. Values 2-4 define a collection of objects that are to 3743 be used to populate the event, condition, or action clauses, 3744 respectively, of a SUPAECAPolicyRule. A value of 4 indicates that 3745 this collection contains objects that define logic for processing 3746 a SUPAPolicy. 3748 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" 3750 This is an optional Boolean attribute. If the value of this 3751 attribute is TRUE, then all elements in this instance of this 3752 SUPAPolicyCollection are ordered. 3754 5.13.3.5. The Attribute "supaPolCollectionType" 3756 This is an optional non-negative enumerated integer that defines 3757 the type of collection that this instance is. Values include: 3759 0: error 3760 1: init 3761 2: set 3762 3: bag (e.g., multi-set) 3763 4: dictionary (e.g., associative array) 3765 Note that 0 and 1 represent error and initialization states, 3766 respectively. A set is an unordered collection of elements that MUST 3767 NOT have duplicates. A bag is an unordered collection of elements; 3768 it MAY have duplicates. A dictionary is a table that associates a 3769 key with a value. 3771 Sets have a number of important functions, including: 3773 o membership: returns TRUE if the element being tested is 3774 in the set, and FALSE otherwise 3775 o subset: returns TRUE if all elements in the first set 3776 are also in the second set 3777 o union: returns all elements from both sets with no 3778 duplicates 3779 o intersection: returns all elements that are in both sets 3780 with no duplicates 3781 o difference: returns all elements in the first set that 3782 are not in the second set 3784 Bags have a number of important functions in addition to the 3785 functions defined for sets (note that while the above set of 3786 functions for a set and a bag are the same, a bag is a different 3787 data type than a set): 3789 o multiplicity: returns the number of occurrences of an 3790 element in the bag 3791 o count: returns the number of all items, including 3792 duplicates 3793 o countDistinct: returns the number of items, where all 3794 duplicates are ignored 3796 A dictionary is an unordered set of key:value pairs, where each 3797 key is unique within a given dictionary. The combination of a 3798 key and a value is called an item. The format of an item is 3799 defined as one element (the key) followed by a colon followed 3800 by a second element (the value). Each item in a set of items is 3801 separated by a comma. Keys MUST NOT be NULL; values MAY be NULL. 3803 An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}. 3804 An example of a null dictionary is simply {}. 3806 5.13.4. SUPAPolicyCollection Relationships 3808 Currently, no relationships are defined for the 3809 SUPAGenericDecoratedComponent class (note that the decorator 3810 pattern obviates the need for relationships such as those in [6]). 3811 SUPAPolicyCollection participates in a single relationship, 3812 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 3814 5.14. The Concrete Class "SUPAPolicySource" 3816 This is an optional class that defines a set of managed entities 3817 that authored, or are otherwise responsible for, this 3818 SUPAPolicyRule. Note that a SUPAPolicySource does NOT 3819 evaluate or execute SUPAPolicies. Its primary use is for 3820 auditability and the implementation of deontic and/or alethic logic. 3821 A class diagram is shown in Figure 12. 3823 A SUPAPolicySource SHOULD be mapped to a role or set of roles 3824 (e.g., using the role-object pattern [11]). This enables 3825 role-based access control to be used to restrict which entities 3826 can author a given policy. Note that Role is a type of 3827 SUPAPolicyMetadata. 3829 5.14.1. SUPAPolicySource Attributes 3831 Currently, no attributes are defined for this class. 3833 5.14.2. SUPAPolicySource Relationships 3835 SUPAPolicySource participates in a single relationship, 3836 SUPAHasPolicySource, as defined in section 5.3.2.1. 3837 SUPAPolicySource, and its subclasses, inherit the 3838 SUPAHasDecoratedPolicyComponent aggregation, which was 3839 defined in section 5.7.3. 3841 5.15. The Concrete Class "SUPAPolicyTarget" 3843 This is an optional class that defines a set of managed entities 3844 that a SUPAPolicy is applied to. Figure 12 shows a class diagram 3845 of the SUPAPolicyTarget. 3847 A managed object must satisfy two conditions in order to be defined 3848 as a SUPAPolicyTarget. First, the set of managed entities that are 3849 to be affected by the SUPAPolicy must all agree to play the role of 3850 a SUPAPolicyTarget. In general, a managed entity may or may not be 3851 in a state that enables SUPAPolicies to be applied to it to change 3852 its state; hence, a negotiation process may need to occur to enable 3853 the SUPAPolicyTarget to signal when it is willing to have 3854 SUPAPolicies applied to it. Second, a SUPAPolicyTarget must be able 3855 to process (directly or with the aid of a proxy) SUPAPolicies. 3857 If a proposed SUPAPolicyTarget meets both of these conditions, it 3858 SHOULD set its supaPolicyTargetEnabled Boolean attribute to a 3859 value of TRUE. 3861 A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the 3862 role-object pattern). This enables role-based access control to 3863 be used to restrict which entities can author a given policy. 3864 Note that Role is a type of SUPAPolicyMetadata. 3866 5.15.1. SUPAPolicyTarget Attributes 3868 Currently, no attributes are defined for the SUPAPolicyTarget 3869 class. 3871 5.15.2. SUPAPolicyTarget Relationships 3873 SUPAPolicyTarget participates in a single relationship, 3874 SUPAHasPolicyTarget, as defined in section 5.3.2.3. 3876 5.16. The Abstract Class "SUPAPolicyMetadata" 3878 Metadata is information that describes and/or prescribes 3879 characteristics and behavior of another object that is **not** 3880 an inherent, distinguishing characteristic or behavior of that 3881 object (otherwise, it would be an integral part of that object). 3883 For example, a socialSecurityNumber attribute should not be part 3884 of a generic Person class. First, most countries in the world do 3885 not know what a social security number is, much less use them. 3886 Second, a person is not created with a social security number; 3887 rather, a social security number is used to track people for 3888 administering social benefits, though it is also used as a form 3889 of identification. 3891 Continuing the example, a better way to add this capability to a 3892 model would be to have a generic Identification class, then 3893 define a SocialSecurityNumber subclass, populate it as necessary, 3894 and then define a composition between a Person and it (this is a 3895 composition because social security numbers are not reused). 3897 Since social security numbers are given to US citizens, permanent 3898 residents, and temporary working residents, and because it is 3899 also used to administer benefits, the composition is realized 3900 as an association class to define how it is being used. 3902 An example of descriptive metadata for network elements would be 3903 documentation about best current usage practices (this could also 3904 be in the form of a reference). An example of prescriptive 3905 metadata for network elements would be the definition of a time 3906 period during which specific types of operations are allowable. 3908 This is an optional class that defines the top of a hierarchy of 3909 model elements that are used to define different types of metadata 3910 that can be applied to policy and policy component objects. This 3911 enables common metadata to be defined as objects and then reused 3912 when the metadata are applicable. One way to control whether 3913 SUPAPolicyMetadata objects are reused is by using the attributes 3914 of the SUPAHasPolicyMetadataDetail association class. 3916 It is recommended that this class, along with its 3917 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator 3918 subclasses, be used as part of a conformant implementation. It is 3919 defined to be optional, since metadata is not strictly required. 3920 However, metadata can help specify and describe SUPAPolicyObject 3921 entities, and can also be used to drive dynamic behavior. 3923 5.16.1. SUPAPolicyMetadata Attributes 3925 This section defines the attributes of the SUPAPolicyMetadata 3926 class. 3928 5.16.1.1. The Attribute "supaPolMetadataDescription" 3930 This is an optional string attribute that defines a free-form 3931 textual description of this metadata object. 3933 5.16.1.2. The Attribute "supaPolMetadataIDContent" 3935 This is a mandatory string attribute that represents part of the 3936 object identifier of an instance of this class. It defines the 3937 content of the object identifier. It works with another class 3938 attribute, called supaPolMetadataIDEncoding, which defines how to 3939 interpret this attribute. These two attributes form a tuple, 3940 and together enable a machine to understand the syntax and value 3941 of an object identifier for the object instance of this class. 3943 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" 3945 This is an optional non-zero enumerated integer attribute that 3946 represents part of the object identifier of an instance of this 3947 class. It defines the format of the object identifier. It works 3948 with another class attribute, called supaPolMetadataIDContent, 3949 which defines the content of the object ID. 3951 These two attributes form a tuple, and together enable a machine 3952 to understand the syntax and value of an object identifier for 3953 the object instance of this class. The supaPolMetadataIDEncoding 3954 attribute is mapped to the following values: 3956 0: error 3957 1: init 3958 2: GUID 3959 3: UUID 3960 4: URI 3961 5: FQDN 3962 6: FQPN 3963 7: string_instance_id 3965 Note that 0 and 1 represent error and initialization states, 3966 respectively. Values 2-6 define the content as a reference. Value 7 3967 defines the content as a string that is the canonical 3968 representation, in ASCII, of an instance ID of this object. 3970 5.16.1.4. The Attribute "supaPolMetadataName" 3972 This is an optional string attribute that defines the name of this 3973 SUPAPolicyMetadata object. 3975 5.16.2. SUPAPolicyMetadata Relationships 3977 SUPAPolicyMetadata participates in a single aggregation, which is 3978 defined in the following subsections. 3980 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" 3982 This is a mandatory aggregation that defines the set of 3983 SUPAPolicyMetadata that are aggregated by this particular 3984 SUPAPolicyObject. It is recommended that this aggregation be used 3985 as part of a conformant implementation. 3987 The multiplicity of this relationship is defined as 0..n on the 3988 aggregate (SUPAPolicyObject) side, and 0..n on the part 3989 (SUPAPolicyMetadata) side. This means that this relationship is 3990 optional. The semantics of this aggregation are implemented using 3991 the SUPAHasPolicyMetadataDetail association class. 3993 5.16.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail" 3995 This is a mandatory concrete association class, and defines the 3996 semantics of the SUPAHasPolicyMetadata aggregation. Its purpose is 3997 to determine which SUPAPolicyMetadata object instances should be 3998 attached to which particular object instances of the 3999 SUPAPolicyObject class. This is done by using the attributes and 4000 relationships of the SUPAPolicyMetadataDetail class to constrain 4001 which SUPAPolicyMetadata objects can be aggregated by which 4002 particular SUPAPolicyObject instances. It is recommended that this 4003 association class be used as part of a conformant implementation. 4005 5.16.2.2.1. The Attribute "supaPolMetadataIsApplicable" 4007 This is an optional Boolean attribute. If the value of this 4008 attribute is TRUE, then the SUPAPolicyMetadata object(s) of this 4009 particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated 4010 by this particular SUPAPolicyObject. 4012 5.16.2.2.2. The Attribute "supaPolMetadataConstraintEncoding" 4014 This is an optional non-negative enumerated integer that defines 4015 how to interpret each string in the supaPolMetadataConstraint 4016 class attribute. Values include: 4018 0: error 4019 1: init 4020 2: OCL 2.4 4021 3: OCL 2.x 4022 4: OCL 1.x 4023 5: QVT 1.2 - Relations Language 4024 6: QVT 1.2 - Operational language 4025 7: Alloy 4026 8: ASCII Text 4028 Enumerations 1 and 2 signify an error state and an initialization 4029 state, respectively. Enumeraitons 3-5 are dedicated to OCL (with 4030 OCL 2.4 being the latest version as of this writing). QVT defines a 4031 set of languages [20] (the two most powerful and useful are defined 4032 by enumerations 5 and 6). Alloy is a language for describing 4033 constraints, and uses a SAT solver to guarantee correctness [21]. 4034 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 4035 and hence, not verifiable), but is included for completeness. 4037 If this class is instantiated, then this attribute SHOULD also be 4038 instantiated, and SHOULD be part of a conformant implementation. 4040 5.16.2.2.3. The Attribute "supaPolMetadataConstraint[0..n]" 4042 This is an optional array of string attributes. Each attribute 4043 specifies a constraint to be applied using the format identified 4044 by the value of the supaPolMetadataPolicyConstraintEncoding class 4045 attribute. This provides a more rigorous and flexible treatment of 4046 constraints than is possible in [RFC3460]. 4048 If this class is instantiated, then this attribute SHOULD also be 4049 instantiated, and should be part of a conformant implementation. 4050 Note: [0..n] means that this is a multi-valued property that has 4051 zero or more attributes. 4053 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" 4055 This is an optional concrete class. It defines an object that will 4056 be wrapped by concrete instances of the SUPAPolicyMetadataDecorator 4057 class. It can be viewed as a "carrier" for metadata that will be 4058 attached to a subclass of SUPAPolicyObject. Since the decorator 4059 pattern is used, any number of concrete subclasses of the 4060 SUPAPolicyMetadataDecorator class can wrap an instance of the 4061 SUPAPolicyConcreteMetadata class. 4063 It is recommended that this class be used as part of a conformant 4064 implementation. 4066 5.17.1. SUPAPolicyConcreteMetadata Attributes 4068 Currently, two attributes are defined for the 4069 SUPAPolicyConcreteMetadata class, and are described in the 4070 following subsections. 4072 5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" 4074 This is an optional attribute. Its data type should be able to 4075 express a date and a time. This attribute defines the ending 4076 date and time that this Metadata object is valid for. 4078 5.17.1.2. The Attribute "supaPolMDValidPeriodStart" 4080 This is an optional attribute. Its data type should be able to 4081 express a date and a time. This attribute defines the starting 4082 date and time that this Metadata object is valid for. 4084 5.17.2. SUPAPolicyConcreteMetadata Relationships 4086 This class inherits the relationships of the SUPAPolicyMetadata 4087 class; see section 5.16.2. It can also be used by subclasses of 4088 the SUPAPolicyMetadataDecorator class, and hence, can participate 4089 in the SUPAHasMetadataDecorator aggregation; see section 5.18.2. 4091 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" 4093 This is an optional class, and is used to implement the decorator 4094 pattern (see section 5.7.1.) for metadata objects. This pattern 4095 enables all or part of one or more SUPAPolicyMetadataDecorator 4096 subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance. 4098 It is recommended that this class be used as part of a conformant 4099 implementation. 4101 5.18.1. SUPAPolicyMetadataDecorator Attributes 4103 Currently, no attributes are defined for the 4104 SUPAPolicyMetadataDecorator class. 4106 5.18.2. SUPAPolicyMetadataDecorator Relationships 4108 This class inherits the relationships of the SUPAPolicyMetadata 4109 class; see section 5.16.2. It also defines a single aggregation, 4110 SUPAHasMetadataDecorator, which is used to implement the decorator 4111 pattern, as described in the following subsections. 4113 5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" 4115 This is an optional aggregation, and is part of a decorator 4116 pattern. It is used to enable a concrete instance of a 4117 SUPAPolicyMetadataDecorator to dynamically add behavior to a 4118 SUPAPolicyConcreteMetadata object instance. The semantics of this 4119 aggregation are defined by the SUPAHasMetadataDecoratorDetail 4120 association class. 4122 It is recommended that this aggregation be part of a conformant 4123 implementation. 4125 The multiplicity of this aggregation is 0..1 on the aggregate 4126 (SUPAPolicyMetadataDecorator) side and 1..n on the part 4127 (SUPAPolicyMetadata) side. This means that if this aggregation is 4128 defined, then at least one SUPAPolicyMetadata object (e.g., a 4129 concrete subclass of SUPAPolicyMetadataDecorator) must also be 4130 instantiated and wrapped by this SUPAPolicyConcreteMetadata object 4131 instance. The semantics of this aggregation are defined by the 4132 SUPAHasMetadataDecoratorDetail association class. 4134 5.18.2.2. The Association Class "SUPAHasMetadataDecoratorDetail" 4136 This is an optional concrete association class, and defines the 4137 semantics of the SUPAHasMetadataDecorator aggregation. The purpose 4138 of this class is to use the Decorator pattern to determine 4139 which SUPAPolicyMetadataDecorator object instances, if any, are 4140 required to augment the functionality of the 4141 SUPAPolicyConcreteMetadata object instance that is being used. 4143 It is recommended that this association class be part of a 4144 conformant implementation. 4146 Attributes for this association class will be defined in a future 4147 version of this document. 4149 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" 4151 This is an optional concrete class that defines access control 4152 information, in the form of metadata, that can be added to a 4153 SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata 4154 aggregation (see section 5.2.2.). This enables all or part of a 4155 standardized description and/or specification of access control 4156 for a given SUPAPolicyObject to be easily changed at runtime by 4157 wrapping an object instance of the SUPAPolicyConcreteMetadata 4158 class (or its subclass) with all or part of this object, and then 4159 adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata 4160 object instance. 4162 5.19.1. SUPAPolicyAccessMetadataDef Attributes 4164 Currently, the SUPAPolicyAccessMetadataDef class defines three 4165 attributes; these are described in the following subsections. 4167 5.19.1.1. The Attribute "supaPolAccessPrivilegeDef" 4169 This is an optional non-negative enumerated integer attribute. It 4170 specifies the access privileges that external Applications have 4171 when interacting with a specific SUPAPolicyObject that is adorned 4172 with an instance of this SUPAPolicyAccessMetadataDef object. This 4173 enables the management system to control, in a consistent manner, 4174 the set of operations that external Applications have for 4175 SUPAPolicies and components of SUPAPolicies. Values include: 4177 0: error 4178 1: init 4179 2: read only (for all policy components) 4180 3: read and write (for all policy components) 4181 4: privileges are specified by an external MAC model 4182 5: privileges are specified by an external DAC model 4183 6: privileges are specified by an external RBAC model 4184 7: privileges are specified by an external ABAC model 4185 8: privileges are specified by an external custom model 4187 Note that 0 and 1 represent error and initialization states, 4188 respectively. Values 4-8 indicate that a formal external access 4189 control model is used. The name of this model, and its location, 4190 are specified in two other class attributes, called 4191 supaPolAccessPrivilegeModelName and supaPolAccessPrivilegeModelRef. 4193 MAC, DAC, RBAC, and ABAC (values 4-7 stand for Mandatory Access 4194 Control, Discretionary Access Control, Role-Based Access Control, 4195 and Attribute-Based Access Control, respectively. They are defined 4196 in [22]. A value of 8 indicates that a formal external model that 4197 is not MAC, DAC, RBAC, or ABAC is used. 4199 5.19.1.2. The Attribute "supaPolAccessPrivilegeModelName" 4201 This is an optional string attribute that contains the name of 4202 the access control model being used. If the value of the 4203 supaPolAccessPrivilegeDef is 0-2, then the value of this attribute 4204 is not applicable. Otherwise, the text in this class attribute 4205 should be interpreted according to the value of the 4206 supaPolAccessPrivilegeModelRef class attribute. 4208 5.19.1.3. The Attribute "supaPolAccessPrivilegeModelRef" 4210 This is an optional non-negative enumerated integer attribute 4211 that defines the data type of the supaPolAccessPrivilegeModelName 4212 attribute. If the value of the supaPolAccessPrivilegeDef class 4213 attribute is 0-2, then the value of this attribute is not 4214 applicable. Otherwise, the value of this class attribute defines 4215 how to interpret the text in the supaPolAccessPrivilegeModelRef 4216 class attribute. Values include: 4218 0: error 4219 1: init 4220 2: GUID 4221 3: UUID 4222 4: URI 4223 5: FQDN 4224 6: FQPN 4225 7: string_instance_id 4227 Note that 0 and 1 represent error and initialization states, 4228 respectively. Values 2-6 define the content as a reference. Value 7 4229 defines the content as a string that is the canonical 4230 representation, in ASCII, of an instance ID of this object. 4232 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" 4234 This is an optional concrete class that defines versioning 4235 information, in the form of metadata, that can be added to a 4236 SUPAPolicyObject. This enables all or part of a standardized 4237 description and/or specification of version information for a 4238 given SUPAPolicyObject to be easily changed at runtime by 4239 wrapping an object instance of the SUPAPolicyConcreteMetadata 4240 class (or its subclass) with all or part of this object. 4242 5.20.1. SUPAPolicyVersionMetadataDef Attributes 4244 Version information is defined in a generic format based on the 4245 Semantic Versioning Specification [18] as follows: 4247 ..[][] 4249 where the first three components (major, minor, and patch) MUST be 4250 present, and the latter two components (pre-release and build- 4251 metadata) MAY be present. A version number MUST take the form 4252 .., where , , and are 4253 each non-negative integers that MUST NOT contain leading zeros. 4254 In addition, the value of each of these three elements MUST 4255 increase numerically. 4257 In this approach: 4259 o supaVersionMajor denotes a new release; this number MUST be 4260 incremented when either changes are introduced that are not 4261 backwards-compatible, and/or new functionality not previously 4262 present is introduced 4263 o supaVersionMinor denotes a minor release; this number MUST be 4264 incremented when new features and/or bug fixes to a major 4265 release that are backwards-compatible are introduced, and/or 4266 if any features are marked as deprecated 4267 o supaVersionPatch denotes a version that consists ONLY of bug 4268 fixes, and MUST be incremented when these bug fixes are Not 4269 backwards-compatible 4271 When multiple versions exist, the following rules define their 4272 precedence: 4274 1. Precedence MUST be calculated by separating the version into 4275 major, minor, patch, and pre-release identifiers, in that 4276 order. Note that build-metadata is NOT used to calculated 4277 precedence. 4278 2. Precedence is determined by the first difference when 4279 comparing each of these identifiers, from left to right, 4280 as follows: 4281 a. Major, minor, and patch versions are always compared 4282 numerically (e.g., 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1) 4283 b. When major, minor, and patch are equal, a pre-release 4284 version has LOWER precedence than a normal version 4285 (e.g., 1.0.0-alpha < 1.0.0) 4286 c. Precedence for two pre-release versions with the same 4287 major, minor, and patch version MUST be determined by 4288 comparing each dot separated identifier from left to 4289 right until a difference is found as follows: 4290 - identifiers consisting only of digits are compared 4291 numerically and identifiers with letters and/or 4292 hyphens are compared lexically in ASCII sort order 4294 - Numeric identifiers always have lower precedence 4295 than non-numeric identifiers 4296 - A larger set of pre-release fields has a higher 4297 precedence than a smaller set, if all of the 4298 preceding identifiers are equal 4299 3. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha-beta 4300 < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0. 4302 Currently, the SUPAPolicyVersionMetadataDef class defines five 4303 attributes; these are described in the following subsections. 4305 5.20.1.1. The Attribute "supaVersionMajor" 4307 This is a mandatory string attribute, and contains a string 4308 representation of an integer that is greater than or equal to zero. 4309 It indicates that a significant increase in functionality is 4310 present in this version. It MAY also indicate that this version has 4311 changes that are NOT backwards-compatible; this MAY be denoted in 4312 the supaVersionBuildMetadata class attribute. 4314 The special string "0.1.0" is for initial development that MUST 4315 NOT be considered stable. Improvements to this initial version, 4316 before they are released to the public, are denoted by incrementing 4317 the minor and patch version numbers. 4319 The major version X (i.e., X.y.z, where X > 0) MUST be incremented 4320 if any backwards incompatible changes are introduced. It MAY 4321 include minor and patch level changes. The minor and patch version 4322 numbers MUST be reset to 0 when the major version number is 4323 incremented. 4325 5.20.1.2. The Attribute "supaVersionMinor" 4327 This is a mandatory string attribute, and contains a string 4328 representation of an integer that is greater than or equal to zero. 4329 It indicates that this release contains a set of features and/or 4330 bug fixes that MUST be backwards-compatible. 4332 The minor version Y (i.e., x.Y.z, where x > 0) MUST be incremented 4333 if new, backwards-compatible changes are introduced. It MUST be 4334 incremented if any features are marked as deprecated. It MAY be 4335 incremented if new functionality or improvements are introduced. 4336 It MAY include patch level changes. The patch version number MUST 4337 be reset to 0 when the minor version number is incremented. 4339 5.20.1.3. The Attribute "supaVersionPatch" 4341 This is a mandatory string attribute, and contains a string 4342 representation of an integer that is greater than or equal to zero. 4343 It indicates that this version contains ONLY bug fixes. 4345 The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented 4346 if new, backwards-compatible changes are introduced. A bug fix is 4347 defined as an internal change that fixes incorrect behavior. 4349 5.20.1.4. The Attribute "supaVersionPreRelease" 4351 This is an optional string attribute, and contains a string 4352 defining the pre-release version. 4354 A pre-release version MAY be denoted by appending a hyphen and a 4355 series of dot-separated identifiers immediately following the patch 4356 version. Identifiers MUST comprise only ASCII alphanumerics and a 4357 hyphen. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT 4358 include leading zeroes. Pre-release versions have a lower 4359 precedence than the associated normal version. A pre-release version 4360 indicates that the version is unstable and might not satisfy the 4361 intended compatibility requirements as denoted by its associated 4362 normal version. Examples include: 1.0.0-alpha, 4363 1.0.0-alpha.1, 1.0.0-0.3.7, and 1.0.0-x.7.z.92. 4365 5.20.1.5. The Attribute "supaVersionBuildMetadata" 4367 This is an optional string attribute, and contains a string defining 4368 the build metadata. Build metadata MAY be denoted by appending a 4369 plus sign and a series of dot-separated identifiers immediately 4370 following the patch or pre-release version. Identifiers MUST be 4371 made up of only ASCII alphanumerics and a hyphen. Identifiers 4372 MUST NOT be empty. Build metadata SHOULD be ignored when determining 4373 version precedence. Examples include: 1.0.0.-alpha+1, 4374 1.0.0+20130313144700, and 1.0.0-beta+exp.sha.5114f85. 4376 6. SUPA ECAPolicyRule Information Model 4378 This section defines the classes, attributes, and relationships 4379 of the SUPA ECAPolicyRule Information Model (EPRIM). Unless 4380 otherwise stated, all classes (and attributes) defined in this 4381 section were abstracted from DEN-ng [2], and a version of them are 4382 in the process of being added to [5]. 4384 6.1. Overview 4386 Conceptually, the EPRIM is a set of subclasses that specialize the 4387 concepts defined in the GPIM for representing the components of a 4388 Policy that uses ECA semantics. This is shown in Figure 23 (only 4389 new EPRIM subclasses and their GPIM superclasses are shown; note 4390 that the SUPAPolicyMetadata hierarchy is used **as is**). 4392 (Class of another model that SUPA is integrating into) 4393 | 4394 +---SUPAPolicyObject (5.2) 4395 | 4396 +---SUPAPolicyStructure (5.3) 4397 | | 4398 | +---SUPAECAPolicyRule (6.4) 4399 | | 4400 | +---SUPAECAPolicyRuleAtomic (6.5) 4401 | | 4402 | +---SUPAECAPolicyRuleComposite (6.6) 4403 | 4404 +---SUPAPolicyComponentStructure (5.6) 4405 | 4406 +---SUPAPolicyClause (5.7) 4407 | | 4408 | +---SUPABooleanClause (6.7) 4409 | | 4410 | +---SUPAECAPolicyRuleAtomic (6.8) 4411 | | 4412 | +---SUPAECAPolicyRuleComposite (6.9) 4413 | 4414 +---SUPAPolicyComponentDecorator (5.9) 4415 | 4416 +---SUPAECAComponent(6.10) 4417 | 4418 +---SUPAPolicyEvent (6.11) 4419 | 4420 +---SUPAPolicyCondition (6.12) 4421 | 4422 +---SUPAPolicyAction (6.13) 4424 Figure 23. The EPRIM Class Hierarchy 4426 Specifically, the EPRIM specializes the SUPAPolicyStructure class 4427 class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it 4428 also specializes two subclasses of the SUPAPolicyComponentStructure 4429 class to create two new sets of policy components. These two 4430 SUPAPolicyComponentStructure subclasses are: 4432 o a new subclass of SUPAPolicyClause, called SUPABooleanClause 4433 (see sections 6.7 - 6.9), is defined for constructing Boolean 4434 clauses that are specific to the needs of ECA Policy Rules 4435 o a new subclass of SUPAPolicyComponentDecorator, called 4436 SUPAECAComponent (see sections 6.10 - 6.13), is defined for 4437 constructing reusable objects that represent Events, 4438 Conditions, and Actions 4440 The EPRIM provides new functionality, based on the GPIM, by 4441 extending the GPIM to define new classes and relationships. The 4442 EPRIM does NOT define new classes that are not inherited from 4443 existing GPIM classes. This ensures that the semantics of the GPIM 4444 are not changed, even though new functionality (for ECA Policy 4445 Rules and components) are being defined. 4447 The overall strategy for refining the GPIM is as follows: 4449 o SUPAECAPolicyRule is defined as a subclass of the GPIM 4450 SUPAPolicyStructure class 4451 o A SUPAECAPolicyRule has event, condition, and action clauses 4452 o Conceptually, this can be viewed as three aggregations 4453 between the SUPAECAPolicyRule and each clause 4454 o Each aggregation uses an instance of a concrete subclass of 4455 SUPAPolicyClause; this can be a SUPABooleanClause 4456 (making it ECA-specific), a SUPAEncodedClause (making it 4457 generic in nature), or a new subclass of SUPAPolicyClause 4458 o Concrete subclasses of SUPAPolicyClause may be decorated 4459 with zero or more concrete subclasses of the 4460 SUPAPolicyComponentDecorator class 4461 o An optional set of GPIM SUPAPolicySource objects can be 4462 defined to represent the authoring of a SUPAECAPolicyRule 4463 o An optional set of GPIM SUPAPolicyTarget objects can be 4464 defined to represent the set of managed entities that will be 4465 affected by this SUPAECAPolicyRule 4466 o An optional set of SUPAPolicyMetadata can be defined for any 4467 of the objects that make up a SUPAECAPolicyRule, including 4468 any of its components 4470 6.2. Constructing a SUPAECAPolicyRule 4472 There are several different ways to construct a SUPAECAPolicyRule; 4473 they differ in which set of components are used to define the 4474 content of the SUPAECAPolicyRule, and whether each component is 4475 decorated or not. The following are some examples of creating a 4476 SUPAECAPolicyRule: 4478 o Define three types of SUPABooleanClauses, one each for the 4479 event, condition, and action clauses that make up a 4480 SUPAECAPolicyRule 4481 o For one or more of the above clauses, associate an 4482 appropriate set of SUPAPolicyEvent, SUPAPolicyCondition, or 4483 SUPAPolicyAction objects, and complete the clause using an 4484 appropriate SUPAPolicyOperator and a corresponding 4485 SUPAPolicyValue or SUPAPolicyVariable 4486 o Note that compound Boolean clauses may be formed using 4487 one or more SUPABooleanClauseComposite objects with one or 4488 more SUPABooleanClauseAtomic objects 4489 o Define a SUPAPolicyCollection component, which is used to 4490 aggregate a set of objects appropriate for a clause, and 4491 complete the clause using an appropriate SUPAPolicyOperator 4492 and a corresponding SUPAPolicyValue or SUPAPolicyVariable 4493 o Create a new concrete subclass of SUPAPolicyComponentStructure 4494 (i.e., a sibling class of SUPAPolicyComponentDecorator and 4495 SUPAPolicyClause), and use this new subclass in a concrete 4496 subclass of SUPABooleanClause; note that this approach enables 4497 the new concrete subclass of SUPAPolicyComponentStructure to 4498 optionally be decorated as well 4499 o Create a new subclass of SUPAPolicyComponentDecorator (e.g., 4500 a sibling of SUPAECAComponent) that provides ECA-specific 4501 functionality, and use that to decorate a SUPAPolicyClause 4502 o Create a new concrete subclass of SUPAPolicyStructure that 4503 provides ECA-specific functionality, and define all or part 4504 of its content by aggregating a set of SUPAPolicyClauses 4506 6.3. Working With SUPAECAPolicyRules 4508 A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that 4509 MUST have three clauses, defined as follows: 4511 o The event clause defines a Boolean expression that, if TRUE, 4512 triggers the evaluation of its condition clause (if the 4513 event clause is not TRUE, then no further action for this 4514 policy rule takes place). 4515 o The condition clause defines a Boolean expression that, if 4516 TRUE, enables the actions in the action clause to be executed 4517 (if the condition clause is not TRUE, then no further action 4518 for this policy rule takes place). 4519 o The action clause contains a set of actions (note that an 4520 action MAY invoke another SUPAECAPolicyRule; see section 4521 6.13). 4523 Each of the above clauses can be a simple Boolean expression (of 4524 the form {variable operator value}, or a compound Boolean 4525 expression consisting of Boolean combinations of clauses. 4526 Compound Boolean expressions SHOULD be in CNF or DNF. 4528 Note that each of the above three clauses MAY have a set of 4529 SUPAPolicyMetadata objects that can constrain, or otherwise 4530 affect, how that clause is treated. For example, a set of 4531 SUPAPolicyMetadata MAY affect whether none, some, or all actions 4532 are executed, and what happens if an action fails. 4534 Each of the three clauses can be constructed from either a 4535 SUPAEncodedClause or a SUPABooleanClause. The advantage of using 4536 SUPAEncodedClauses is simplicity, as the content of the clause is 4537 encoded directly into the attributes of the SUPAEncodedClause. The 4538 advantage of using SUPABooleanClauses is reusability, since each 4539 term in each clause is potentially a reusable object. 4541 Since a SUPABooleanClause is a subclass of a SUPAPolicyClause 4542 (see Section 6.7), it can be decorated by one or more concrete 4543 subclasses of SUPAPolicyComponentDecorator. Therefore, a 4544 SUPAECAPolicyRule can be built entirely from objects defined in 4545 the GPIM and EPRIM, which facilitates the construction of 4546 SUPAPolicies by a machine. 4548 The relation between a SUPAECAPolicyRule and a SUPAPolicyClause 4549 is shown in Figure 24, and is explained in further detail in 4550 Section 6.4. 4552 SUPAHasPolicyClause 4553 +----------------+------------------------+ 4554 | ^ | 4555 | | | 4556 / \ | | 4557 A | | 4558 A \ / 0..1 | A 1..n \ / 4559 +----------+-----------+ | +-----------+------+ 4560 | SUPAPolicyStructure | | | SUPAPolicyClause | 4561 +----------+-----------+ | +-----------+------+ 4562 / \ | / \ 4563 I A | | 4564 I +----------+----------------+ | 4565 I | SUPAHasPolicyClauseDetail | | 4566 I +---------------------------+ | 4567 I | 4568 C I A | 4569 +----------+----------+ +--------+----------+ 4570 | SUPAECAPolicyRule | | SUPABooleanClause | 4571 +---------------------+ +-------------------+ 4573 Figure 24. SUPAECAPolicyRule Clauses 4575 The SUPAHasPolicyClause aggregation is implemented using the 4576 SUPAHasPolicyClauseDetail association class. These were 4577 described in sections 5.4.2.1 and 5.4.2.2, respectively. 4579 6.4. The Abstract Class "SUPAECAPolicyRule" 4581 This is a mandatory abstract class, which is a PolicyContainer 4582 that aggregates PolicyEvents, PolicyConditions, PolicyActions into 4583 a type of policy rule known as an Event-Condition-Action (ECA) 4584 policy rule. As previously explained, this has the following 4585 semantics: 4587 IF the event clause evaluates to TRUE 4588 IF the condition clause evaluates to TRUE 4589 THEN execute actions in the action clause 4590 ENDIF 4591 ENDIF 4593 The event clause, condition clause, and action clause collectively 4594 form a three-tuple. Each clause MUST be defined by at least one 4595 SUPAPolicyClause (which MAY be decorated with other elements, 4596 as described in section 5.7). 4598 Each of the three types of clauses is a 3-tuple of the form: 4600 {variable operator value} 4602 Each of the three clauses MAY be combined with additional clauses 4603 using any combination of logical AND, OR, and NOT operators; this 4604 forms a "compound" Boolean clause. For example, if A, B, and C are 4605 three attributes in an event, then a valid event clause could be: 4607 (A AND B) OR C 4609 Note that the above expression is in DNF; the equivalent CNF form 4610 is ((A OR C) AND (B OR C)). In either case, the output of all 4611 three clauses is either TRUE or FALSE; this facilitates combining 4612 and chaining SUPAECAPolicyRules. 4614 An action clause MAY invoke a new SUPAECAPolicyRule; see section 4615 6.13 for more details. 4617 An ECAPolicyRule MAY be optionally augmented with PolicySources 4618 and/or PolicyTargets (see sections 5.16 and 5.17, respectively). 4619 In addition, all objects that make up a SUPAECAPolicyRule MAY 4620 have SUPAPolicyMetadata (see section 5.16) attached to them to 4621 further describe and/or specify behavior. 4623 When defined in an information model, each of the event, condition, 4624 and action clauses MUST be represented as an aggregation between a 4625 SUPAECAPolicyRule (the aggregate) and a set of event, condition, 4626 or action objects (the components). However, a data model MAY map 4627 these definitions to a more efficient form (e.g., by flattening 4628 these three types of object instances, along with their respective 4629 aggregations, into a single object instance). 4631 The composite pattern [3] is applied to the SUPAECAPolicyRule 4632 class, enabling its (concrete) subclasses to be used as either a 4633 stand-alone policy rule or as a hierarchy of policy rules. 4634 SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both 4635 inherit from SUPAECAPolicyRule. This means that they are both 4636 a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule 4637 aggregation enables a particular SUPAECAPolicyRuleComposite 4638 object to aggregate both SUPAECAPolicyRuleComposite as well as 4639 SUPAECAPolicyRuleAtomic objects. In contrast, a 4640 SUPAECAPolicyRuleAtomic can NOT aggregate either a 4641 SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. 4642 SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are 4643 defined in sections 6.5 and 6.6, respectively. This is 4644 shown in Figure 25. 4646 A 4647 1..n +-------------------+ 4648 \| | 4649 +--------------- + SUPAECAPolicyRule | 4650 | /| | 4651 | +--------+----------+ 4652 | / \ 4653 | SUPAHasECAPolicyRule I 4654 | I 4655 | I 4656 | I 4657 | +---------------+-------------+ 4658 | I I 4659 / \ I I 4660 A I I 4661 C \ / 0..1 I C I 4662 +-----+---------+----------+ +-----------+-----------+ 4663 |SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic| 4664 +--------------------------+ +-----------------------+ 4666 Figure 25. The Composite Pattern Applied to a SUPAECAPolicyRule 4668 Note that the HasSUPAECAPolicyRule aggregation is defined by the 4669 HasSUPAECAPolicyRuleDetail association class; both are defined 4670 in sections 6.6.2 and 6.6.3, respectively. 4672 6.4.1. SUPAECAPolicyRule Attributes 4674 Currently, the SUPAECAPolicyRule defines two attributes, as 4675 described in the following subsections. 4677 6.4.1.1. The Attribute "supaECAPolicyRulePriority" 4679 This is a mandatory non-negative integer attribute that defines 4680 the priority of this particular SUPAECAPolicyRule. A larger value 4681 indicates a higher priority. A default value of 0 MAY be assigned. 4683 Priority is used primarily for 2 reasons: (1) to resolve conflicts 4684 among policy actions (e.g., given a set of conflicting actions, 4685 which one will execute) and (2) to define the execution order of 4686 policy actions (e.g., when one action may depend on the output of 4687 one or more previous actions). 4689 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" 4691 This is an optional non-negative enumerated integer whose value 4692 defines the current status of this policy rule. Values include: 4694 0: error 4695 1: init 4696 2: In development, not ready to be deployed 4697 1: Ready to be deployed 4698 2: Deployed but not enabled 4699 3: Deployed and enabled, but not executed 4700 4: Executed without errors 4701 5: Executed with errors 4702 6: Aborted during execution 4704 Note that 0 and 1 represent error and initialization states, 4705 respectively. 4707 6.4.2. SUPAECAPolicyRule Relationships 4709 Currently, the SUPAECAPolicyRule does not define any 4710 relationships. It inherits all four relationships defined by 4711 the SUPAPolicyStructure class (see section 5.3.2.). 4713 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" 4715 This is a mandatory concrete class. This class is a type of 4716 PolicyContainer, and represents a SUPAECAPolicyRule that can 4717 operate as a single, stand-alone, manageable object. Put another 4718 way, a SUPAECAPolicyRuleAtomic object can NOT be modeled as a set 4719 of hierarchical SUPAECAPolicyRule objects; if this is required, 4720 then a SUPAECAPolicyRuleComposite object should be used instead. 4722 6.5.1. SUPAECAPolicyRuleAtomic Attributes 4724 Currently, the SUPAECAPolicyRuleAtomic class does not define any 4725 attributes. 4727 6.5.2. SUPAECAPolicyRuleAtomic Relationships 4729 Currently, the SUPAECAPolicyRuleAtomic class does not define any 4730 relationships. It inherits all four relationships defined by the 4731 SUPAPolicyStructure class (see section 5.3.2.). 4733 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" 4735 This is a mandatory concrete class. This class is a type of 4736 PolicyContainer, and represents a SUPAECAPolicyRule as a hierarchy 4737 of SUPAPolicy objects, where the hierarchy contains instances of a 4738 SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects. 4739 Each of the SUPAPolicy objects, including the outermost 4740 SUPAECAPolicyRuleComposite object, are separately manageable. More 4741 importantly, each SUPAECAPolicyRuleComposite object represents an 4742 aggregated object that is itself manageable. 4744 6.6.1. SUPAECAPolicyRuleComposite Attributes 4746 Currently, the SUPAECAPolicyRuleComposite defines one attribute, 4747 as described in the following subsection. 4749 6.6.1.1. The Attribute "supaECAEvalStrategy" 4751 This is a mandatory, non-zero, integer attribute that enumerates 4752 a set of allowable alternatives that define how the set of 4753 SUPAECAPolicyRule object instances in a SUPAECAPolicyRuleComposite 4754 object are evaluated. It is assumed that the event and condition 4755 clauses of the SUPAECAPolicyRules have evaluated to TRUE (e.g., the 4756 event has occurred and the conditions were met). Values include: 4758 0: error 4759 1: init 4760 2: execute the first SUPAECAPolicyRule in the 4761 SUPAECAPolicyRuleComposite and then terminate 4762 3: execute only the highest priority SUPAECAPolicyRule(s) in 4763 the SUPAECAPolicyRuleComposite and then terminate 4764 4: execute all SUPAECAPolicyRules in prioritized order (if 4765 any) regardless of whether their SUPAPolicyActions 4766 succeed or fail 4767 5: execute all SUPAECAPolicyRules in prioritized order (if 4768 any) until at least one SUPAPolicyAction in a 4769 SUPAECAPolicyRule fails, and then terminate 4771 Note that 0 and 1 represent error and initialization states, 4772 respectively. 4774 If the value of supaECAEvalStrategy is 3 or 4, then all 4775 SUPAECAPolicyRules that have a priority will be executed first 4776 (starting with the SUPAECAPolicyRule(s) that have the highest 4777 priority, and descending); all SUPAECAPolicyRule(s) that do not 4778 have a priority are then executed (in any order). 4780 Assume that the actions in a given SUPAECAPolicyRuleComposite 4781 are defined as follows 4783 SUPAECAPolicyRule A, priority 0 4784 SUPAECAPolicyRule B, priority 10 4785 SUPAECAPolicyRule C, priority 5 4786 SUPAECAPolicyRule D, priority 10 4787 SUPAECAPolicyRule E, priority 2 4789 Then, if the supaECAEvalStrategy attribute value equals: 4791 0: an error is issued 4792 1: this SUPAECAPolicyRule MUST NOT be used (since it is not yet 4793 properly initialized) 4794 2: only SUPAECAPolicyRule A is executed 4795 3: only SUPAECAPolicyRules B and D are executed 4796 4: all SUPAECAPolicyRules are executed, regardless of any 4797 failures in their SUPAPolicyActions 4798 5: all SUPAECAPolicyRules are executed until a failure is 4799 detected, and then execution for all SUPAECAPolicyRules 4800 terminates 4802 6.6.2. SUPAECAPolicyRuleComposite Relationships 4804 Currently, the SUPAECAPolicyRuleComposite defines a single 4805 aggregation between it and SUPAECAPolicyRule, as described below. 4807 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" 4809 This is an optional aggregation that implements the composite 4810 pattern. The multiplicity of this aggregation is 0..1 on the 4811 aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part 4812 (SUPAECAPolicyRule) side. This means that if this aggregation 4813 is defined, then at least one SUPAECAPolicyRule object (which may 4814 be either an instance of a SUPAECAPolicyRuleAtomic or a 4815 SUPAECAPolicyRuleComposite class) must also be instantiated and 4816 aggregated by this particular SUPAECAPolicyRuleComposite object. 4817 The semantics of this aggregation are defined by the 4818 SUPAHasECAPolicyRuleDetail association class. 4820 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" 4822 This is an optional concrete association class, and defines the 4823 semantics of the SUPHasECAPolicyRule aggregation. This enables the 4824 attributes and relationships of the SUPAHasECAPolicyRuleDetail 4825 class to be used to constrain which SUPHasECAPolicyRule objects 4826 can be aggregated by this particular SUPAECAPolicyRuleComposite 4827 object instance. 4829 6.6.3.1. The Attribute "supaECAPolicyIsDefault" 4831 This is an optional Boolean attribute. If the value of this 4832 attribute is true, then this SUPAECAPolicyRule is a default 4833 policy, and will be executed if no other SUPAECAPolicyRule 4834 in the SUPAECAPolicyRuleComposite container has been executed. 4835 This is a convenient way for error handling, though care should 4836 be taken to ensure that only one default policy rule is defined 4837 per SUPAECAPolicyRuleComposite container. 4839 6.7. The Abstract Class "SUPABooleanClause" 4841 A SUPABooleanClause specializes a SUPAPolicyClause, and defines 4842 a Boolean expression consisting of a standard structure in the 4843 form of a SUPAPolicyVariable, a SUPAPolicyOperator, and a 4844 SUPAPolicyValue. For example, this enables the following Boolean 4845 clause to be defined: 4847 Foo >= Baz 4849 where 'Foo' is a PolicyVariable, '>=' is a PolicyOperator, and 4850 'Baz' is a PolicyValue. 4852 Note that in this approach, the SUPAPolicyVariable and 4853 SUPAPolicyValue terms are defined as an appropriate subclass of 4854 the SUPAPolicyComponentDecorator class; it is assumed that the 4855 SUPAPolicyOperator is an instance of the SUPAPolicyOperator class. 4857 This enables the EPRIM, in conjunction with the GPIM, to be used 4858 as a reusable class library. This encourages interoperability, 4859 since each element of the clause is itself an object defined by 4860 the SUPA object hierarchy. 4862 An entire SUPABooleanClause may be negated by setting the 4863 supaBoolClauseIsNegated class attribute of the SUPABooleanClause 4864 class to TRUE. Individual terms of a Boolean clause can be negated 4865 by using the supaTermIsNegated Boolean attribute in the 4866 SUPAPolicyTerm class (see section 5.10). 4868 A PolicyClause is in Conjunctive Normal Form (CNF) if it is a 4869 sequence of logically ANDed terms, where each term is a sequence 4870 of logically ORed terms. 4872 A PolicyClause is in Disjunctive Normal Form (DNF) if it is a 4873 sequence of logically ORed terms, where each term is a sequence 4874 of logically ANDed terms. 4876 The construction of more complex clauses, which consist of a set 4877 of simple clauses in CNF or DNF (as shown in the above example), 4878 is provided by using the composite pattern [3] to construct two 4879 concrete subclasses of the abstract SUPABooleanClause class. These 4880 are called SUPABooleanClauseAtomic and SUPABooleanClauseComposite, 4881 and are defined in sections 6.8 and 6.9, respectively. This 4882 enables instances of either a SUPABooleanClauseAtomic and/or a 4883 SUPABooleanClauseComposite to be aggregated into a 4884 SUPABooleanClauseComposite object. 4886 6.7.1. SUPABooleanClause Attributes 4888 The SUPABooleanClause class currently defines one attribute, 4889 which are defined in the following subsections. 4891 6.7.1.1. The Attribute "supaBoolClauseIsNegated" 4893 This is a mandatory Boolean attribute. If the value of this 4894 attribute is TRUE, then this (entire) SUPABooleanClause is 4895 negated. Note that the supaPolTermIsNegated class attribute of 4896 the SUPAPolicyTerm class is used to negate a single term. 4898 6.7.2. SUPABooleanClause Relationships 4900 Currently, no relationships are defined for the SUPABooleanClause 4901 class. It inherits the relationships of SUPAPolicyClause (see 4902 section 5.5.). 4904 6.8. The Concrete Class "SUPABooleanClauseAtomic" 4906 This is a mandatory concrete class that represents a 4907 SUPABooleanClause that can operate as a single, stand-alone, 4908 manageable object. A SUPABooleanClauseAtomic object can NOT be 4909 modeled as a set of hierarchical clauses; if this functionality is 4910 required, then a SUPABooleanClauseComposite object must be used. 4911 Examples of Boolean clauses that could be contained in a 4912 SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P 4913 and Q are literals (e.g., a variable name that can be either true 4914 or false, or a formula that evaluates to a literal). Examples of 4915 Boolean clauses that are NOT in CNF are NOT(P AND Q), 4916 (P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent 4917 forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and 4918 P AND (Q OR S) AND (Q OR S), respectively. 4920 6.8.1. SUPABooleanClauseAtomic Attributes 4922 No attributes are currently defined for the 4923 SUPABooleanClauseAtomic class. 4925 6.8.2. SUPABooleanClauseAtomic Relationships 4927 Currently, no relationships are defined for the 4928 SUPABooleanClauseAtomic class. It inherits the relationships of 4929 SUPAPolicyClause (see section 5.5.). 4931 6.9. The Concrete Class "SUPABooleanClauseComposite" 4933 This is a mandatory concrete class that represents a 4934 SUPABooleanClause that can operate as a hierarchy of PolicyClause 4935 objects, where the hierarchy contains instances of 4936 SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite 4937 objects. Each of the SUPABooleanClauseAtomic and 4938 SUPABooleanClauseComposite objects, including the outermost 4939 SUPABooleanClauseComposite object, are separately manageable. 4941 More importantly, each SUPAECAPolicyRuleComposite object 4942 represents an aggregated object that is itself manageable. 4943 Examples of Boolean clauses that could be contained in a 4944 SUPABooleanClauseAtomic include ((P OR Q) AND R), and 4945 ((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, and 4946 T are literals. 4948 6.9.1. SUPABooleanClauseComposite Attributes 4950 Two attributes are currently defined for the 4951 SUPABooleanClauseComposite class, and are described in the 4952 following subsections. 4954 6.9.1.1. The Attribute "supaBoolClauseBindValue" 4956 This is a mandatory non-zero integer attribute, and defines the 4957 order in which terms bind to a clause. For example, the Boolean 4958 expression "((A AND B) OR (C AND NOT (D OR E)))" has the following 4959 binding order: terms A and B have a bind value of 1; term C has a 4960 binding value of 2, and terms D and E have a binding value of 3. 4962 6.9.1.2. The Attribute "supaBoolClauseIsCNF" 4964 This is an optional Boolean attribute. If the value of this 4965 attribute is TRUE, then this SUPABooleanClauseComposite is in CNF 4966 form. Otherwise, it is in DNF form. 4968 6.9.2. SUPABooleanClauseComposite Relationships 4970 Currently, the SUPABooleanClauseComposite class defined a single 4971 aggregation, which is described in the subsections below. 4973 6.9.2.1. The Aggregation "SUPAHasBooleanClause" 4975 This is a mandatory aggregation that defines the set of 4976 SUPABooleanClause objects that are aggregated by this 4977 SUPABooleanClauseComposite object. 4979 The multiplicity of this relationship is 0..1 on the aggregate 4980 (SUPABooleanClauseComposite) side, and 1..n on the part 4981 (SUPABooleanClause) side. This means that one or more 4982 SUPABooleanClauses are aggregated and used to define this 4983 SUPABooleanClauseComposite object. The 0..1 cardinality on the 4984 SUPABooleanClauseComposite side is necessary to enable 4985 SUPABooleanClauses to exist (e.g., in a PolicyRepository) before 4986 they are used by a SUPABooleanClauseComposite. The semantics of 4987 this aggregation is defined by the SUPAHasBooleanClauseDetail 4988 association class. 4990 6.9.3. The Association Class "SUPAHasBooleanClauseDetail" 4992 This is a mandatory concrete association class that defines the 4993 semantics of the SUPAHasBooleanClause aggregation. This enables the 4994 attributes and relationships of the SUPAHasBooleanClauseDetail 4995 class to be used to constrain which SUPABooleanClause objects 4996 can be aggregated by this particular SUPABooleanClauseComposite 4997 object instance. 4999 6.9.3.1. SUPAHasBooleanClauseDetail Attributes 5001 The SUPAHasBooleanClauseDetail class currently does not define 5002 any attributes. 5004 6.10. The Abstract Class "SUPAECAComponent" 5006 This is a mandatory abstract class that defines three concrete 5007 subclasses, one each to represent the concepts of reusable events, 5008 conditions, and actions. They are called SUPAPolicyEvent, 5009 SUPAPolicyCondition, and SUPAPolicyAction, respectively. 5011 SUPAECAComponents provide two different ways to construct 5012 SUPAPolicyClauses. The first is for the SUPAECAComponent to be 5013 used as either a SUPAPolicyVariable or a SUPAPolicyValue, and the 5014 second is for the SUPAECAComponent to contain the entire clause 5015 text. 5017 For example, suppose it is desired to define a policy condition 5018 clause with the text 'queueDepth > 10'. The two approaches could 5019 satisfy this as follows: 5021 Approach #1 (canonical form): 5022 SUPAPolicyCondition.supaPolicyConditionData contains the text 5023 'queueDepth' 5024 SUPAPolicyOperator.supaPolOpType is set to '1' (greater than) 5025 SUPAPolicyValue.supaPolValContent is set to '10' 5027 Approach #2 (SUPAECAComponent represents the entire clause): 5028 SUPAPolicyCondition.supaPolicyConditionData contains the text 5029 'queueDepth > 10' 5031 The class attribute supaECACompIsTerm, defined in subsection 5032 6.10.1.1, is used to identify which of these two approaches is 5033 used by an object instance of this class. 5035 6.10.1. SUPAECAComponent Attributes 5037 A single attribute is currently defined for this class, and is 5038 described in the following subsection. 5040 6.10.1.1. The Attribute supaECACompIsTerm 5042 This is an optional Boolean attribute. If the value of this 5043 attribute is TRUE, then this SUPAECAComponent is used as the value 5044 of a SUPAPolicyTerm to construct a SUPAPolicyClause (this is 5045 approach #1 in section 6.10 above). If the value of this attribute 5046 is FALSE, then this SUPAECAComponent contains the text of the 5047 entire corresponding SUPAPolicyClause (this is approach #2 in 5048 section 6.10 above). 5050 6.10.2. SUPAECAComponent Relationships 5052 No relationships are currently defined for this class. 5054 6.11. The Concrete Class "SUPAPolicyEvent" 5056 This is a mandatory concrete class that represents the concept of 5057 an Event that is applicable to a policy management system. Such 5058 an Event is defined as anything of importance to the management 5059 system (e.g., a change in the system being managed and/or its 5060 environment) occuring on a time-axis (as defined in [19]). 5061 SUPAPolicyEvents can be used as part of a SUPAPolicyClause; this 5062 is done by specifying the attribute name and value of an Event in 5063 the supaPolicyEventData attribute of the SUPAPolicyEvent. This 5064 enables event attributes to be used as part of a SUPAPolicyClause. 5066 Note: this class does NOT model the "raw" occurrences of Events. 5067 Rather, it represents the concept of an Event object whose class 5068 attributes describe pertinent attributes that can trigger the 5069 evaluation of a SUPAECAPolicyRule. 5071 6.11.1. SUPAPolicyEvent Attributes 5073 Currently, five attributes are defined for the SUPAPolicyEvent 5074 class, which are described in the following subsections. 5076 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 5078 This is an optional Boolean attribute. If the value of this 5079 attribute is TRUE, then this SUPAPolicyEvent has been pre- 5080 processed by an external entity, such as an Event Service Bus, 5081 before it was received by the Policy Management System. 5083 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" 5085 This is an optional Boolean attribute. If the value of this 5086 attribute is TRUE, then this SUPAPolicyEvent has been produced by 5087 the Policy Management System. If the value of this attribute is 5088 FALSE, then this SUPAPolicyEvent has been produced by an entity 5089 in the system being managed. 5091 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" 5093 This is a mandatory array of string attributes, and contains the 5094 subject that this PolicyEvent describes. 5095 Note: [0..n] means that this is a multi-valued property that has 5096 zero or more attributes. 5098 6.11.1.4. The Attribute "supaPolicyEventEncoding" 5100 This is a mandatory non-zero enumerated integer attribute, and 5101 defines how to interpret the supaPolicyEventData class attribute. 5102 These two attributes form a tuple, and together enable a machine 5103 to understand the syntax and value of the data carried by the 5104 object instance of this class. Values include: 5105 0: error 5106 1: init 5107 2: String 5108 3: Integer 5109 4: Boolean 5110 5: Floating Point 5111 6: DateTime 5113 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" 5115 This is a mandatory attribute that defines an array of strings. 5116 Each string in the array represents an attribute name and value 5117 of an Event object. The format of each string is defined as 5118 name:value. The 'name' part is the name of the SUPAPolicyEvent 5119 attribute, and the 'value' part is the value of that attribute. 5121 Note: [1..n] means that this is a multi-valued property that has 5122 at least one (and possibly more) attributes. For example, if 5123 this value of this attribute is: 5125 {(startTime:0800), (endTime:1700), (date:2016-05-11), 5126 (timeZone:-08:00)} 5128 then this attribute contains four properties, called startTime, 5129 endTime, date, and timeZone whose values are 0800, 1700, May 11 5130 2016, and Pacific Standard Time, respectively. 5132 Note that the supaPolicyEventEncoding class attribute defines how 5133 to interpret the value portion of this attribute. 5135 This attribute works with another class attribute, called 5136 supaPolicyEventEncoding, which defines how to interpret this 5137 attribute. These two attributes form a tuple, and together enable 5138 a machine to understand the syntax and value of the data carried 5139 by the object instance of this class. 5141 6.11.2. SUPAPolicyEvent Relationships 5143 No relationships are currently defined for this class. It inherits 5144 the relationships defined by the SUPAPolicyComponentDecorator (see 5145 section 5.7.3.). 5147 6.12. The Concrete Class "SUPAPolicyCondition" 5149 This is a mandatory concrete class that represents the concept of 5150 an Condition that will determine whether or not the set of Actions 5151 in the SUPAECAPolicyRule to which it belongs are executed or not. 5152 SUPAPolicyConditions can be used as part of a SUPAPolicyClause 5153 (e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or as a 5154 stand-alone SUPAPolicyClause (e.g., the supaPolicyConditionData 5155 attribute contains text that defines the entire condition clause). 5157 6.12.1. SUPAPolicyCondition Attributes 5159 Currently, two attributes are defined for the SUPAPolicyCondition 5160 class, which are described in the following subsections. 5162 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 5164 This is a mandatory array of string attributes that contains the 5165 content of this SUPAPolicyCondition object. 5166 Note: [1..n] means that this is a multi-valued property that has 5167 at least one (and possibly more) attributes. 5169 This attribute works with another class attribute, called 5170 supaPolicyConditionEncoding, which defines how to interpret this 5171 attribute. These two attributes form a tuple, and together enable 5172 a machine to understand the syntax and value of the data carried 5173 by the object instance of this class. 5175 6.12.1.2. The Attribute "supaPolicyConditionEncoding" 5177 This is a mandatory non-zero enumerated integer attribute, and 5178 defines the data type of the supaPolicyConditionData attribute. 5179 These two attributes form a tuple, and together enable a machine 5180 to understand the syntax and value of the content of this 5181 SUPAPolicyCondition object. Values include: 5183 0: error 5184 1: init 5185 2: OCL 2.4 5186 3: OCL 2.x 5187 4: OCL 1.x 5188 5: QVT 1.2 - Relations Language 5189 6: QVT 1.2 - Operational language 5190 7: Alloy 5191 8: ASCII Text 5193 Enumerations 1 and 2 signify an error state and an initialization 5194 state, respectively. Enumeraitons 3-5 are dedicated to OCL (with 5195 OCL 2.4 being the latest version as of this writing). QVT defines a 5196 set of languages [20] (the two most powerful and useful are defined 5197 by enumerations 5 and 6). Alloy is a language for describing 5198 constraints, and uses a SAT solver to guarantee correctness [21]. 5199 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 5200 and hence, not verifiable), but is included for completeness. 5202 If this class is instantiated, then this attribute SHOULD also be 5203 instantiated, and SHOULD be part of a conformant implementation. 5205 6.12.2. SUPAPolicyEvent Relationships 5207 No relationships are currently defined for this class. It inherits 5208 the relationships defined by the SUPAPolicyComponentDecorator (see 5209 section 5.7.3.). 5211 6.13. The Concrete Class "SUPAPolicyAction" 5213 This is a mandatory concrete class that represents the concept of 5214 an Action, which is a part of a SUPAECAPolicyRule, which may be 5215 executed when both the event and the condition clauses of its 5216 owning SUPAECAPolicyRule evaluate to true. The execution of this 5217 action is determined by its SUPAECAPolicyRule container, and any 5218 applicable SUPAPolicyMetadata objects. SUPAPolicyActions can be 5219 used in three different ways: 5221 o as part of a SUPAPolicyClause (e.g., var = 5222 SUPAPolicyAction.supaPolicyActionData) 5223 o as a stand-alone SUPAPolicyClause (e.g., the 5224 supaPolicyActionData attribute contains text that defines 5225 the entire action clause) 5226 o to invoke a SUPAECAPolicyRule 5228 In the third case, the execution semantics SHOULD be to suspend 5229 the current execution of the set of SUPAPolicyActions that are 5230 executing, transfer execution control to the invoked 5231 SUPAECAPolicyRule, and resume the execution of the original set 5232 of SUPAPolicyActions when the invoked SUPAECAPolicyRule has 5233 finished execution. 5235 6.13.1. SUPAPolicyAction Attributes 5237 Currently, two attributes are defined for the SUPAPolicyCondition 5238 class, which are described in the following subsections. 5240 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" 5242 This is a mandatory array of string attributes that contains the 5243 content of this SUPAPolicyAction object. This attribute works with 5244 another class attribute, called supaPolicyActionEncoding, which 5245 defines how to interpret this attribute. These two attributes form 5246 a tuple, and together enable a machine to understand the syntax 5247 and value of the data carried by the object instance of this class. 5248 Note: [1..n] means that this is a multi-valued property that has 5249 at least one (and possibly more) attributes. 5251 Since this attribute could represent a term in a SUPAPolicyClause 5252 (e.g., var = SUPAPolicyAction.supaPolicyActionData), a complete 5253 SUPAPolicyClause (e.g., the supaPolicyActionData attribute 5254 contains text that defines the entire action clause), or the 5255 name of a SUPAECAPolicyRule to invoke, each element in the string 5256 array is prepended with one of the following strings: 5258 o 't:' (or 'term:'), to denote a term in a SUPAPolicyClause 5259 o 'c:' (or 'clause:'), to denote an entire SUPAPolicyClause 5260 o 'r:' (or 'rule:'), to invoke a SUPAECAPolicyRule 5262 6.13.1.2. The Attribute "supaPolicyActionEncoding" 5264 This is a mandatory non-zero enumerated integer attribute, and 5265 defines the data type of the supaPolicyActionData attribute. This 5266 attribute works with another class attribute, called 5267 supaPolicyActionData, which contains the content of the action. 5268 These two attributes form a tuple, and together enable a machine 5269 to understand the syntax and value of the content of this 5270 SUPAPolicyAction object. Values include: 5272 0: error 5273 1: init 5274 2: OCL 2.4 5275 3: OCL 2.x 5276 4: OCL 1.x 5277 5: QVT 1.2 - Relations Language 5278 6: QVT 1.2 - Operational language 5279 7: Alloy 5280 8: ASCII Text 5281 9: GUID 5282 10: UUID 5283 11: URI 5284 12: FQDN 5286 Enumerations 1 and 2 signify an error state and an initialization 5287 state, respectively. Enumeraitons 3-5 are dedicated to OCL (with 5288 OCL 2.4 being the latest version as of this writing). QVT defines a 5289 set of languages [20] (the two most powerful and useful are defined 5290 by enumerations 5 and 6). Alloy is a language for describing 5291 constraints, and uses a SAT solver to guarantee correctness [21]. 5292 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 5293 and hence, not verifiable), but is included for completeness. 5294 Enumerations 9-12 define a reference to the SUPAPolicyAction. 5296 If this class is instantiated, then this attribute SHOULD also be 5297 instantiated, and SHOULD be part of a conformant implementation. 5299 6.13.2. SUPAPolicyAction Relationships 5301 No relationships are currently defined for this class. It inherits 5302 the relationships defined by the SUPAPolicyComponentDecorator (see 5303 section 5.7.3.). 5305 Enumerations 1-4 are used to provide a reference to an action 5306 object. Enumerations 5-10 are used to express the action to 5307 perform as a string. 5309 7. Examples 5311 This will be defined in the next version of this document. 5313 8. Security Considerations 5315 This will be defined in the next version of this document. 5317 9. IANA Considerations 5319 This document has no actions for IANA. 5321 10. Contributors 5323 The following people contributed to creating this document, and are 5324 listed in alphabetical order: 5326 Jason Coleman 5328 11. Acknowledgments 5330 This document has benefited from reviews, suggestions, comments 5331 and proposed text provided by the following members, listed in 5332 alphabetical order: Andy Bierman, Bert Wijnen, Bob Natale, Dave 5333 Hood, Fred Feisullin, Georgios Karagiannis, Liu (Will) Shucheng, 5334 Marie-Jose Montpetit. 5336 12. References 5338 This section defines normative and informative references for this 5339 document. 5341 12.1. Normative References 5343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5344 Requirement Levels", BCP 14, RFC 2119, March 1997. 5346 12.2. Informative References 5348 [RFC3060] Moore, B., Ellesson, E., Strassner, J., Westerinen, 5349 A., "Policy Core Information Model -- Version 1 5350 Specification", RFC 3060, February 2001 5352 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 5353 Scherling, M., Quinn, B., Herzog, S., Huynh, A., 5354 Carlson, M., Perry, J., Waldbusser, S., "Terminology 5355 for Policy-Based Management", RFC 3198, November, 2001 5357 [RFC3460] Moore, B., ed., "Policy Core Information Model (PCIM) 5358 Extensions, RFC 3460, January 2003 5360 [1] Strassner, J., "Policy-Based Network Management", 5361 Morgan Kaufman, ISBN 978-1558608597, Sep 2003 5363 [2] Strassner, J., ed., "The DEN-ng Information Model", 5364 add stable URI 5366 [3] Riehle, D., "Composite Design Patterns", Proceedings 5367 of the 1997 Conference on Object-Oriented Programming 5368 Systems, Languages and Applications (OOPSLA '97). 5369 ACM Press, 1997, Page 218-228 5371 [4] DMTF, CIM Schema, v2.44, 5372 http://dmtf.org/standards/cim/cim_schema_v2440 5374 [5] Strassner, J., ed., "ZOOM Policy Architecture and 5375 Information Model Snapshot", TR235, part of the 5376 TM Forum ZOOM project, October 26, 2014 5378 [6] TM Forum, "Information Framework (SID), GB922 and 5379 associated Addenda, v14.5, 5380 https://www.tmforum.org/information-framework-sid/ 5382 [7] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 5383 subtyping", ACM Transactions on Programming languages 5384 and Systems 16 (6): 1811 - 1841, 1994 5386 [8] Klyus, M., Strassner, J., Liu, W., Karagiannis, G., 5387 Bi, J., "SUPA Value Proposition", 5388 draft-klyus-supa-value-proposition-00, March 21, 2016 5390 [9] ISO/IEC 10746-3 (also ITU-T Rec X.903), "Reference 5391 Model Open Distributed Processing Architecture", 5392 April 20, 2010 5394 [10] Davy, S., Jennings, B., Strassner, J., "The Policy 5395 Continuum - A Formal Model", Proc. of the 2nd Intl. 5396 IEEE Workshop on Modeling Autonomic Communication 5397 Environments (MACE), Multicon Lecture Notes, No. 6, 5398 Multicon, Berlin, 2007, pages 65-78 5400 [11] Gamma, E., Helm, R., Johnson, R., Vlissides, J., 5401 "Design Patterns - Elements of Reusable Object-Oriented 5402 Software", Addison-Wesley, 1994, ISBN 0-201-63361-2 5404 [12] Strassner, J., de Souza, J.N., Raymer, D., Samudrala, 5405 S., Davy, S., Barrett, K., "The Design of a Novel 5406 Context-Aware Policy Model to Support Machine-Based 5407 Learning and Reasoning", Journal of Cluster Computing, 5408 Vol 12, Issue 1, pages 17-43, March, 2009 5410 [13] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 5411 subtyping", ACM Transactions on Programming languages 5412 and Systems, 16 (6): 1811 - 1841, 1994 5414 [14] Martin, R.C., "Agile Software Development, Principles, 5415 Patterns, and Practices", Prentice-Hall, 2002, 5416 ISBN: 0-13-597444-5 5418 [15] Halpern, J., Strassner, J., "Generic Policy Data Model 5419 for Simplified Use of Policy Abstractions (SUPA)" 5420 draft-ietf-supa-generic-policy-data-model-02, 5421 July 13, 2016 5423 [16] Wang, Y., Esposito, F., Matta, I., Day, J., "RINA: An 5424 Architecture for Policy-based Dynamic Service 5425 Management", Tech Report BUCS-TR-2013-014, 2013 5427 [17] Meyer, B., "Object-Oriented Software Construction", 5428 Prentice Hall, second edition, 1997 ISBN 0-13-629155-4 5430 [18] http://semver.org/ 5432 [19] ISO/IEC:2004(E), "Data elements and interchange 5433 formats -- Information interchange -- Representation 5434 of dates and times", 2004 5436 [20] http://www.omg.org/spec/QVT/ 5438 [21] http://alloy.mit.edu/alloy/ 5440 Authors' Addresses 5442 John Strassner 5443 Huawei Technologies 5444 2330 Central Expressway 5445 Santa Clara, CA 95138 USA 5446 Email: john.sc.strassner@huawei.com 5448 Joel Halpern 5449 Ericsson 5450 P. O. Box 6049 5451 Leesburg, VA 20178 5452 Email: joel.halpern@ericsson.com 5454 Sven van der Meer 5455 LM Ericsson Ltd. 5456 Ericsson Software Campus 5457 Garrycastle 5458 Athlone 5459 N37 PV44 5460 Ireland 5461 Email: sven.van.der.meer@ericsson.com 5463 Appendix A. Brief Analyses of Previous Policy Work 5465 This appendix describes of some of the important problems with 5466 previous IETF policy work., and describes the rationale for 5467 taking different design decisions in this document. 5469 A.1. PolicySetComponent vs. SUPAPolicyStructure 5471 The ability to define different types of policy rules is not 5472 present in [RFC3060] and [RFC3460], because both are based on [4], 5473 and this ability is not present in [4]. [RFC3060], [RFC3460], and 5474 [4] are all limited to CA (condition-action) policy rules. In 5475 addition, events are NOT defined. These limitations mean that 5476 RFC3060], [RFC3460], and [4] can only represent CA Policy Rules. 5478 In contrast, the original design goal of SUPA was to define a 5479 single class hierarchy that could represent different types of 5480 policies (e.g., imperative and declarative). Hence, it was 5481 decided to make SUPAPolicyStructure generic in nature, so that 5482 different types of policies could be defined as subclasses. This 5483 enables a single Policy Framework to support multiple types of 5484 policies. 5486 A.2. Flat Hierarchy vs. SUPAPolicyComponentStructure 5488 Figure 26 shows a portion of the class hierarchy of [RFC3460]. 5490 A 5491 +--------+ 5492 | Policy | 5493 +----+---+ 5494 / \ 5495 | 5496 | 5497 +---------+------+------+------------+-----------+ 5498 | | | | | 5499 A | | A | | A | 5500 +-----+-----+ | +--------+--------+ | +------+-------+ 5501 | PolicySet | | | PolicyCondition | | | PolicyAction | 5502 +-----+-----| | +--------+--------+ | +------+-------+ 5503 / \ | / \ | / \ 5504 | | | | | 5505 ... | ... | ... 5506 A | A | 5507 +-------+--------+ +-------+-----+ 5508 | PolicyVariable | | PolicyValue | 5509 +-------+--------+ +-------+-----+ 5510 / \ / \ 5511 | | 5512 ... ... 5514 Figure 26. Simplified Class Hierarcy of [RFC3460] 5516 RFC3060], [RFC3460], and [4] defined PolicyConditions and 5517 PolicyActions as subclasses of Policy (along with PolicySet, 5518 which is the superclass of PolicyRules and PolicyGroups). This 5519 means that there is no commonality between PolicyConditions and 5520 PolicyActions, even though they are both PolicyRule components. 5521 From an object-oriented point-of-view, this is incorrect, since a 5522 PolicyRule aggregates both PolicyConditions and PolicyActions. 5524 In addition, note that both PolicyVariables and PolicyValues are 5525 siblings of PolicyRules, PolicyConditions, and PolicyActions. This 5526 is incorrect for several reasons: 5528 o a PolicyRule cannot rectly contain PolicyVariables or 5529 PolicyValues, so they shouldn't be at the same level of the 5530 class hierarchy 5531 o both PolicyConditions and PolicyActions can contain 5532 PolicyVariables and PolicyValues, which implies that both 5533 PolicyVariables and PolicyValues should be lower in the 5534 class hierarchy 5536 Note that in the current version of [4], PolicyVariable and 5537 PolicyValue are both deleted. There are other changes as well, 5538 but they are beyond the scope of this Appendix. 5540 The original design goal of SUPA was to define a single class 5541 hierarchy that could represent different types of policies and 5542 policy components. This cannot be accomplished in [RFC3460], since 5543 there is no notion of a policy component (or alternatively, 5544 PolicyCondition, PolicyAction, PolicyVariable, and PolicyValue are 5545 all components at the same abstraction level, which is clearly not 5546 correct). Hence, SUPA defined the SUPAPolicyComponentStructure 5547 class to capture the concept of a reusable policy component. 5549 In summary, SUPAPolicyStructure subclasses define the structure of 5550 a policy in a common way, while SUPAPolicyComponentStructure 5551 subclasses define the content that is contained in the structure 5552 of a policy, also in a common way. 5554 A.3. PolicyRules and PolicyGroups vs. SUPAPolicyRules 5556 A PolicySetComponent is an aggregation, implemented as an 5557 association class, that "collects instances of PolicySet 5558 subclasses into coherent sets of Policies". This is a recursive 5559 aggregation, with multiplicity 0..n - 0..n, on the PolicySet 5560 class. 5562 Since this is a recursive aggregation, it means that a PolicySet 5563 can aggregate zero or more PolicySets. This is under-specified, 5564 and can be interpreted in one of two ways: 5566 1. A PolicySet subclass can aggregate any PolicySet subclass 5567 (PolicyRules can aggregate PolicyRules and PolicyGroups, and 5568 vice-versa) 5569 2. PolicyRules can aggregate PolicyRules, and PolicyGroups can 5570 aggregate PolicyGroups, but neither class can aggregate the 5571 other type of class 5573 Both interpretations are ill-suited for policy-based management. 5574 The problem with the first is that if PolicyGroup is the mechanism 5575 for grouping, why can a PolicyRule aggregate a PolicyGroup? This 5576 implies that PolicyGroups are not needed. The problem with the 5577 second is that PolicyGroups cannot aggregate PolicyRules (which 5578 again implies that PolicyGroups are not needed). 5580 Furthermore, there are no mechanisms defined in the [RFC3460] 5581 model to prevent loops of PolicyRules. This is a problem, because 5582 EVERY PolicyRule and PolicyGroup inherits this recursive 5583 aggregation. 5585 This is why this document uses the composite pattern. First, this 5586 pattern clearly shows what object is aggregating what other 5587 object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate a 5588 SUPAECAPolicyRuleComposite). Second, it does not allow a 5589 SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule 5590 (this is discussed more in the following subsection). 5592 A.3.1. Sub-rules 5594 Sub-rules (also called nested policy rules) enable a policy rule to 5595 be contained within another policy rule. These have very complex 5596 semantics, are very hard to debug, and provide limited value. They 5597 also require a complex set of aggregations (see section A.4.). 5599 The main reason for defining sub-rules in [RFC3460] is to enable 5600 "complex policy rules to be constructed from multiple simpler 5601 policy rules". However, the composite pattern does this much more 5602 efficiently than a simple recursive aggregation, and avoids the 5603 ambiguous semantics of a recursive aggregation. This latter point 5604 is important, because if PolicyRule and/or PolicyGroup is 5605 subclassed, then all subclasses still inherit this recursive 5606 aggregation, along with its ambiguous semantics. 5608 A.4. PolicyConditions and PolicyActions vs. SUPAECAComponent 5610 There is no need to use the SimplePolicyCondition and 5611 ComplexPolicyCondition objects defined in [RFC3460], since the 5612 SUPAPolicyComponentStructure uses the decorator pattern (see 5613 section 5.7) to provide more extensible types of conditions than is 5614 possible with those classes. This also applies for the 5615 SimplePolicyAction and the ComplexPolicyAction classes defined in 5616 [RFC3460]. 5618 More importantly, this removes the need for a complex set of 5619 aggregations (i.e., PolicyComponent, PolicySetComponent, 5620 PolicyConditionStructure, PolicyConditionInPolicyRule, 5621 PolicyConditionInPolicyCondition, PolicyActionStructure, 5622 PolicyActionInPolicyRule, and PolicyActionInPolicyAction). 5623 Instead, ANY SUPAECAComponent is defined as a decorator (i.e., a 5624 subclass of SUPAPolicyComponentDecorator), and hence, Any 5625 SUPAECAComponent is wrapped onto a concrete subclass of 5626 SUPAPolicyClause using the SAME aggregation 5627 (SUPAHasDecoratedPolicyComponent). This is a significantly simpler 5628 design that is also more powerful. 5630 A.5. The SUPAPolicyComponentDecorator Abstraction 5632 One of the problems in building a policy model is the tendency to 5633 have a multitude of classes, and hence object instances, to 5634 represent different combinations of policy events, conditions, and 5635 actions. This can lead to class and/or relationship explosion, as 5636 is the case in [RFC3460], [4], and [6]. 5638 For example, [RFC3460] defines five subclasses of PolicyCondition: 5639 PolicyTimePeriodCondition, VendorPolicyCondition, 5640 SimplePolicyCondition, CompoundPolicyCondition, and 5641 CompoundFilterCondition. Of these: 5643 o PolicyTimePeriodCondition is a data structure, not a class 5644 o VendorPolicyCondition represents a condition using two 5645 attributes that represent a multi-valued octet string 5646 o SimplePolicyCondition, CompoundPolicyCondition, and 5647 CompoundFilterCondition all have ambiguous semantics 5649 SimplePolicyCondition represents an ordered 3-tuple, in the form 5650 {variable, match, value}. However, the match operator is not 5651 formally modeled. Specifically, "the 'match' relationship is to 5652 be interpreted by analyzing the variable and value instances 5653 associated with the simple condition". This becomes problematic 5654 for several cases, such as shallow vs. deep object comparisons. 5655 More importantly, this requires two separate aggregations 5656 (PolicyVariableInSimplePolicyCondition and 5657 PolicyValueInSimplePolicyCondition) to associate variables and 5658 values to the SimplePolicyCondition, respectively. Since [RFC3460] 5659 defines all relationships as classes, this means that the 5660 expression "Foo > Bar" requires a total of FIVE objects (one each 5661 for the variable and value, one for the SimplePolicyCondition, and 5662 one each to associate the variable and value with the 5663 SimplePolicyCondition). 5665 This is exacerbated when SimplePolicyConditions are used to build 5666 CompoundPolicyConditions. In addition to the above complexity 5667 (which is required for each SimplePolicyCondition), a new 5668 aggregation (PolicyConditionInPolicyCondition) is required to 5669 aggregation PolicyConditions. Thus, the compound expression: 5670 "((Foo > Bar) AND (Foo < Baz))" requires a total of THIRTEEN 5671 objects (five for each of the terms being ANDed, plus one for the 5672 CompoundPolicyCondition, and two to aggregate each term to the 5673 CompoundPolicyCondition). 5675 Note that in the above examples, the superclasses of each of the 5676 relationships are omitted for clarity. In addition, [RFC3460] is 5677 built using inheritance; this means that if a new function is 5678 required, a new class must be built (e.g., CompoundFilterCondition 5679 is a subclass, but all it adds is one attribute). 5681 In constrast, the Decorator Pattern enables behavior to be 5682 selectively added to an individual object, either statically or 5683 dynamically, without having to build association classes. In 5684 addition, the decorator pattern uses composition, instead of 5685 inheritance, to avoid class explosion. This means that a new 5686 variable, value, or even condition class can be defined at 5687 runtime, and then all or part of that class can dynamically wrap 5688 an existing object without need for recompilation and 5689 redeployment. 5691 A.6. The Abstract Class "SUPAPolicyClause" 5693 This abstraction is missing in [RFC3060], [RFC3460], [4], and [6]. 5694 SUPAPolicyClause was abstracted from DEN-ng [2], and a version of 5695 this class is in the process of being added to [5]. However, the 5696 class and relationship design in [5] differs significantly from 5697 the corresponding designs in this document. 5699 SUPAPolicyClause further reinforces the different between a policy 5700 rule and a component of a policy rule by abstracting the content 5701 of a policy rule as a reusable object. This is fundamental for 5702 enabling different types of policy rules (e.g., imperative and 5703 declarative) to to be represented using the same constructs. 5705 A.7. Problems with the RFC3460 Version of PolicyVariable 5707 The following subsections define a brief, and incomplete, set of 5708 problems with the implementation of [RFC3460] (note that [RFC3060 5709 did not define variables, operators, and/or values). 5711 A.7.1. Object Bloat 5713 [RFC3460] used two different and complex mechanisms for providing 5714 generic get and set expressions. PolicyVariables were subclassed 5715 into two subclasses, even though they performed the same semantic 5716 function. This causes additional problems: 5718 o PolicyExplicitVariables are for CIM compatibility; note that 5719 the CIM does not contain either PolicyVariables or 5720 PolicyValues ([4]) 5721 o PolicyImplicitVariable subclasses do not define attributes; 5722 rather, they are bound to an appropriate subclass of 5723 PolicyValue using an association 5725 Hence, defining a variable is relatively expensive in [RFC3460], 5726 as in general, two objects and an association must be used. The 5727 objects themselves do not define content; rather, their names are 5728 used as a mechanism to identify an object to match. This means 5729 that an entire object must be used (instead of, for example, an 5730 attribute), which is wasteful. It also make it difficult to 5731 adjust constraints at runtime, since the constraint is defined in 5732 a class that is statically defined (and hence, requires 5733 recompilation and possibly redeployment if it is changed). 5735 A.7.2. Object Explosion 5737 The above three problems lead to class explosion (recall that in 5738 [RFC3060], [RFC3460], and [4], associations are implemented as 5739 classes). 5741 In contrast to this approach, the approach in this document keeps 5742 the idea of the class hierarchy for backwards compatibility, but 5743 streamlines the implementation. Specifically: 5745 1. The decorator pattern is an established and very used 5746 software pattern (it dates back to at least 1994 [11]). 5747 2. The use of a single association class 5748 (i.e., SUPAHasDecoratedPolicyComponentDetail) can represent 5749 more constraints than is possible in the approaches of 5750 [RFC3460] and [4] in a much more flexible manner, due to its 5751 function as a decorator of other objects. 5752 3. Note that there is no way to enforce the constraint matching 5753 in [RFC3460] and [6]; the burden is on the developer to 5754 check and see if the constraints specified in one class are 5755 honored in the other class. 5756 4. If these constraints are not honored, there is no mechanism 5757 specified to define the clause as incorrectly formed. 5759 A.7.3. Specification Ambiguities 5761 There are a number of ambiguities in [RFC3460]. 5763 First, [RFC3460] says: "Variables are used for building individual 5764 conditions". While this is true, variables can also be used for 5765 building individual actions. This is reflected in the definition 5766 for SUPAPolicyVariable. 5768 Second, [RFC3460] says: "The variable specifies the property of a 5769 flow or an event that should be matched when evaluating the 5770 condition." While this is true, variables can be used to test many 5771 other things than "just" a flow or an event. This is reflected in 5772 the SUPAPolicyVariable definition. 5774 Third, the [RFC3460] definition requires the use of associations 5775 in order to properly constrain the variable (e.g., define its 5776 data type, the range of its allowed values, etc.). This is both 5777 costly and inefficient. 5779 Fourth, [RFC3460] is tightly bound to the DMTF CIM schema [4]. 5780 The CIM is a data model (despite its name), because: 5782 o It uses keys and weak relationships, which are both concepts 5783 from relational algebra and thus, not technology-independent 5784 o It has its own proprietary modeling language 5785 o It contains a number of concepts that are not defined in UML 5786 (including overriding keys for subclasses) 5788 Fifth, the class hierarchy has two needless classes, called 5789 SUPAImplicitVariable and SUPAExplicitVariable. These classes do 5790 not define any attributes or relationships, and hence, do not 5791 add any semantics to the model. 5793 Finally, in [RFC3460], defining constraints for a variable is 5794 limited to associating the variable with a PolicyValue. This is 5795 both cumbersome (because associations are costly; for example, 5796 they equate to a join in a relational database management system), 5797 and not scalable, because it is prone to proliferating PolicyValue 5798 classes for every constraint (or range of constraints) that is 5799 possible. Therefore, in SUPA, this mechanism is replaced with 5800 using an association to an association class that defines 5801 constraints in a much more general and powerful manner (i.e., 5802 the SUPAHasDecoratedPolicyComponentDetail class). 5804 A.8. Problems with the RFC3460 Version of PolicyValue 5806 The following subsections define a brief, and incomplete, set of 5807 problems with the implementation of [RFC3460] (note that [RFC3060 5808 did not define variables, operators, and/or values). 5810 A.8.1. Object Bloat 5812 [RFC3460] defined a set of 7 subclasses; three were specific to 5813 networking (i.e., IPv4 Address, IPv6 Address, MAC Address) and 4 5814 (PolicyStringValue, PolicyBitStringValue, PolicyIntegerValue, and 5815 PolicyBooleanValue) were generic in nature. However, each of these 5816 objects defined a single class attribute. This has the same two 5817 problems as with PolicyVariables (see section 5.9.1.1): 5819 1. Using an entire object to define a single attribute is very 5820 wasteful and expensive 5821 2. It also make it difficult to adjust constraints at runtime, 5822 since the constraint is defined in a class that is statically 5823 defined (and hence, requires recompilation and possibly 5824 redeployment if it is changed). 5826 A.8.2. Object Explosion 5828 [RFC3460] definition requires the use of associations 5829 in order to properly constrain the variable (e.g., define its 5830 data type, the range of its allowed values, etc.). This is both 5831 costly and inefficient (recall that in [RFC3060], [RFC3460], and 5832 [4], associations are implemented as classes). 5834 A.8.3. Lack of Constraints 5836 There is no generic facility for defining constraints for a 5837 PolicyValue. Therefore, there is no facility for being able to 5838 change such constraints dynamically at runtime. 5840 A.8.4. Tightly Bound to the CIM Schema 5842 [RFC3460] is tightly bound to the DMTF CIM schema [4]. The CIM is 5843 a data model (despite its name), because: 5845 o It uses keys and weak relationships, which are both concepts 5846 from relational algebra and thus, not technology-independent 5847 o It has its own proprietary modeling language 5848 o It contains a number of concepts that are not defined in UML 5849 (including overriding keys for subclasses) 5851 A.8.5. Specification Ambiguity 5853 [RFC3460] says: It is used for defining values and constants used 5854 in policy conditions". While this is true, variables can also be 5855 used for building individual actions. This is reflected in the 5856 SUPAPolicyVariable definition. 5858 A.8.6. Lack of Symmetry 5860 Most good information models show symmetry between like components. 5861 [RFC3460] has no symmetry in how it defines variables and values. 5862 In contrast, this document recognizes that variables and values 5863 are just terms in a clause; hence, the only difference in the 5864 definition of the SUPAPolicyVariable and SUPAPolicyValue classes 5865 is that the content attribute in the former is a single string, 5866 whereas the content attribute in the latter is a string array. 5867 In particular, the semantics of both variables and values are 5868 defined using the decorator pattern, along with the attributes of 5869 the SUPAPolicyComponentDecorator and the 5870 SUPAHasDecoratedPolicyComponentDetail classes.