idnits 2.17.1 draft-ietf-supa-generic-policy-info-model-01.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 19, 2016) is 2810 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6020' is defined on line 5237, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 5241, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 5316, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-supa-generic-policy-data-model-00 Summary: 0 errors (**), 0 flaws (~~), 6 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: January 19, 2017 S. van der Meer 5 Ericsson 6 July 19, 2016 8 Generic Policy Information Model for 9 Simplified Use of Policy Abstractions (SUPA) 10 draft-ietf-supa-generic-policy-info-model-01 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 January 19, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 54 1. Overview ....................................................... 9 55 1.1. Introduction .............................................. 9 56 1.2. Changes Since Version -03 ................................ 11 57 2. Conventions Used in This Document ............................. 11 58 3. Terminology ................................................... 12 59 3.1. Acronyms ................................................. 12 60 3.2. Definitions .............................................. 12 61 3.2.1. Core Terminology .................................... 12 62 3.2.1.1. Information Model .............................. 12 63 3.2.1.2. Data Model ..................................... 13 64 3.2.1.3. Class .......................................... 13 65 3.2.1.3.1. Abstract Class ............................... 13 66 3.2.1.3.2. Concrete Class ............................... 13 67 3.2.1.4. Container ...................................... 13 68 3.2.1.5. PolicyContainer ................................ 13 69 3.2.2. Policy Terminology .................................. 14 70 3.2.2.1. SUPAPolicyObject ............................... 14 71 3.2.2.2. SUPAPolicy ..................................... 14 72 3.2.2.3. SUPAPolicyClause ............................... 14 73 3.2.2.4. SUPAECAPolicyRule .............................. 15 74 3.2.2.5. SUPAMetadata ................................... 15 75 3.2.2.6. SUPAPolicyTarget ............................... 15 76 3.2.2.7. SUPAPolicySource ............................... 15 77 3.2.3. Modeling Terminology ................................ 16 78 3.2.3.1. Inheritance .................................... 16 79 3.2.3.2. Relationship ................................... 16 80 3.2.3.3. Association .................................... 17 81 3.2.3.4. Aggregation .................................... 17 82 3.2.3.5. Composition .................................... 17 83 3.2.3.6. Association Class .............................. 17 84 3.2.3.7. Multiplicity ................................... 18 85 3.2.3.8. Navigability ................................... 18 86 3.3. Symbology ................................................ 18 87 3.3.1. Inheritance ......................................... 18 88 3.3.2. Association ......................................... 19 89 3.3.3. Aggregation ......................................... 19 90 3.3.4. Composition ......................................... 19 91 3.3.5. Association Class ................................... 19 92 3.3.6. Abstract vs. Concrete Classes ....................... 20 93 4. Policy Abstraction Architecture ............................... 21 94 4.1. Motivation ............................................... 22 95 4.2. SUPA Approach ............................................ 23 97 Table of Contents (continued) 99 4.3. SUPA Generic Policy Information Model Overview............ 23 100 4.3.1. SUPAPolicyObject .................................... 25 101 4.3.2. SUPAPolicyStructure ................................. 26 102 4.3.3. SUPAPolicyComponentStructure ........................ 26 103 4.3.4. SUPAPolicyClause .................................... 27 104 4.3.5. SUPAPolicyComponentDecorator ........................ 27 105 4.3.6. SUPAPolicyTarget .................................... 28 106 4.3.7. SUPAPolicySource .................................... 28 107 4.4. The Design of the GPIM ................................... 28 108 4.4.1. Structure of Policies ............................... 29 109 4.4.2. Representing an ECA Policy Rule ..................... 30 110 4.4.3. Creating SUPA Policy Clauses ........................ 33 111 4.4.4. Creating SUPAPolicyClauses .......................... 36 112 4.4.5. SUPAPolicySources ................................... 37 113 4.4.6. SUPAPolicyTargets ................................... 39 114 4.4.7. SUPAPolicyMetadata .................................. 39 115 4.4.7.1. Motivation ..................................... 39 116 4.4.7.2. Design Approach ................................ 40 117 4.4.7.2.1. Policies and Actors ....................... 42 118 4.4.7.2.2. Deployment vs. Execution of Policies ...... 43 119 4.4.7.2.3. Using SUPAMetadata for Policy Deployment 120 and Execution ............................. 43 121 4.4.7.3. Structure of SUPAPolicyMetadata ................ 44 122 4.5. Advanced Features ........................................ 47 123 4.5.1. Policy Grouping ..................................... 47 124 4.5.2. Policy Rule Nesting ................................. 47 125 5. GPIM Model .................................................... 48 126 5.1. Overview ................................................. 48 127 5.2. The Abstract Class "SUPAPolicyObject" .................... 49 128 5.2.1. SUPAPolicyObject Attributes ......................... 50 129 5.2.1.1. Object Identifiers ............................. 50 130 5.2.1.2. The Attribute "supaPolObjIDContent" ............ 51 131 5.2.1.3. The Attribute "supaPolObjIDEncoding" ........... 51 132 5.2.1.4. The Attribute "supaPolicyDescription" .......... 51 133 5.2.1.5. The Attribute "supaPolicyName" ................. 51 134 5.2.2. SUPAPolicy Relationships ............................ 52 135 5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 52 136 5.2.2.2. The Association Class 137 "SUPAHasPolicyMetadataDetail" .................. 52 138 5.3. The Abstract Class "SUPAPolicyStructure" ................. 52 139 5.3.1. SUPAPolicyStructure Attributes ...................... 53 140 5.3.1.1. The Attribute "supaPolAdminStatus" ............. 53 141 5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 53 142 5.3.1.3. The Attribute "supaPolDeployStatus" ............ 54 143 5.3.1.4. The Attribute "supaPolExecStatus" .............. 54 144 5.3.1.5. 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 "supaPolExecFailTakeActionEncoding" ....... 57 164 5.3.2.6.2. The Attribute 165 "supaPolExecFailTakeActionName[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 "supaPolClauseExecStatus" ........ 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 "supaEncodedClauseResponse" ...... 62 181 5.6.1.4. The Attribute "supaEncodedClauseLang[0..n]" .... 62 182 5.6.1.5. The Attribute "supaEncodedClauseResponse" ...... 62 183 5.6.2. SUPAEncodedClause Relationships ..................... 62 184 5.7. The Abstract Class "SUPAPolicyComponentDecorator" ........ 62 185 5.7.1. The Decorator Pattern ............................... 63 186 5.7.2. SUPAPolicyComponentDecorator Attributes ............. 64 187 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 65 188 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 65 189 5.7.3. SUPAPolicyComponentDecorator Relationships .......... 65 190 5.7.3.1. The Aggregation 191 "SUPAHasDecoratedPolicyComponent" .............. 66 192 5.7.3.2. The Association Class 193 "SUPAHasDecoratedPolicyComponentDetail" ........ 66 194 5.7.3.2.1. The Attribute 195 "supaDecoratedConstraintEncoding" ......... 66 196 5.7.3.2.2. The Attribute 197 "supaDecoratedConstraint[0..n]" ........... 67 199 Table of Contents (continued) 201 5.7.4. Illustration of Constraints in the Decorator Pattern 67 202 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 68 203 5.8.1. SUPAPolicyTerm Attributes ........................... 69 204 5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 69 205 5.8.2. SUPAPolicyTerm Relationships ........................ 69 206 5.9. The Concrete Class "SUPAPolicyVariable" .................. 69 207 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 70 208 5.9.2. SUPAPolicyVariable Attributes ....................... 70 209 5.9.2.1. The Attribute "supaPolVarName" ................. 70 210 5.9.3. SUPAPolicyVariable Relationships .................... 70 211 5.10. The Concrete Class "SUPAPolicyOperator" ................. 70 212 5.10.1. Problems with the RFC3460 Version .................. 71 213 5.10.2. SUPAPolicyOperator Attributes ...................... 71 214 5.10.2.1. The Attribute "supaPolOpType" ................. 71 215 5.10.3. SUPAPolicyOperator Relationships ................... 71 216 5.11. The Concrete Class "SUPAPolicyValue" .................... 72 217 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 72 218 5.11.2. SUPAPolicyValue Attributes ......................... 72 219 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 72 220 5.11.2.2. The Attribute "supaPolValEncoding" ............ 73 221 5.11.3. SUPAPolicyValue Relationships ...................... 73 222 5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 73 223 5.12.1. SUPAGenericDecoratedComponent Attributes ........... 74 224 5.12.1.1. The Attribute 225 "supaVendorDecoratedCompContent[0..n]" ........ 74 226 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 74 227 5.12.2. SUPAGenericDecoratedComponent Relationships ........ 74 228 5.13. The Concrete Class "SUPAPolicyCollection" ............... 75 229 5.13.1. Motivation ......................................... 75 230 5.13.2. Solution ........................................... 75 231 5.13.3. SUPAPolicyCollection Attributes .................... 76 232 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 76 233 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 76 234 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 76 235 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 76 236 5.13.3.5. The Attribute "supaPolCollectionType" ......... 77 237 5.13.4. SUPAPolicyCollection Relationships ................. 78 238 5.14. The Concrete Class "SUPAPolicySource" .................... 78 239 5.14.1. SUPAPolicySource Attributes ........................ 78 240 5.14.2. SUPAPolicySource Relationships ..................... 78 241 5.15. The Concrete Class "SUPAPolicyTarget" ................... 78 242 5.15.1. SUPAPolicyTarget Attributes ........................ 79 243 5.15.2. SUPAPolicyTarget Relationships ..................... 79 245 Table of Contents (continued) 247 5.16. The Abstract Class "SUPAPolicyMetadata" ................. 79 248 5.16.1. SUPAPolicyMetadata Attributes ...................... 80 249 5.16.1.1. The Attribute "supaPolMetadataDescription" .... 80 250 5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 80 251 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 80 252 5.16.1.4. The Attribute "supaPolMetadataName" ........... 81 253 5.16.2. SUPAPolicyMetadata Relationships ................... 81 254 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 81 255 5.16.2.2. The Association Class 256 "SUPAHasPolicyMetadataDetail" ................. 81 257 5.16.2.2.1. The Attribute 258 "supaPolMetadataIsApplicable" ............ 81 259 5.16.2.2.2. The Attribute 260 "supaPolMetadataConstraintEncoding" ...... 82 261 5.16.2.2.3. The Attribute 262 "supaPolMetadataConstraint[0..n]" ........ 82 263 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 82 264 5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 83 265 5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" ...... 83 266 5.17.1.2. The Attribute "supaPolMDValidPeriodStart" .... 83 267 5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 83 268 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 83 269 5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 83 270 5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 83 271 5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" .... 84 272 5.18.2.2. The Association Class 273 "SUPAHasMetadataDecoratorDetail" .............. 84 274 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 84 275 5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 85 276 5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 85 277 5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 85 278 5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 86 279 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 86 280 5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 86 281 5.20.1.1. The Attribute "supaVersionMajor" .............. 87 282 5.20.1.2. The Attribute "supaVersionMinor" .............. 88 283 5.20.1.3. The Attribute "supaVersionPatch" .............. 88 284 5.20.1.4. The Attribute "supaVersionPreRelease" ......... 88 285 5.20.1.5. The Attribute "supaVersionBuildMetadata" ...... 89 286 6. SUPA ECAPolicyRule Information Model .......................... 89 287 6.1. Overview ................................................. 89 288 6.2. Constructing a SUPAECAPolicyRule ......................... 91 289 6.3. Working With SUPAECAPolicyRules .......................... 92 290 6.4. The Abstract Class "SUPAECAPolicyRule" ................... 93 291 6.4.1. SUPAECAPolicyRule Attributes ........................ 95 292 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 95 293 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ........ 95 294 6.4.2. SUPAECAPolicyRule Relationships ..................... 96 296 Table of Contents (continued) 298 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 96 299 6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 96 300 6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 96 301 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 96 302 6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 96 303 6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 97 304 6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 97 305 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 98 306 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 98 307 6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 98 308 6.7. The Abstract Class "SUPABooleanClause" ................... 98 309 6.7.1. SUPABooleanClause Attributes ........................ 99 310 6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 99 311 6.7.2. SUPABooleanClause Relationships ..................... 99 312 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............ 100 313 6.8.1. SUPABooleanClauseAtomic Attributes ................. 100 314 6.8.2. SUPABooleanClauseAtomic Relationships .............. 100 315 6.9. The Concrete Class "SUPABooleanClauseComposite" ......... 100 316 6.9.1. SUPABooleanClauseComposite Attributes .............. 100 317 6.9.1.1. The Attribute "supaBoolClauseBindValue" ....... 101 318 6.9.1.2. The Attribute "supaBoolClauseIsCNF" ........... 101 319 6.9.2. SUPABooleanClauseComposite Relationships ........... 101 320 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ........ 101 321 6.9.3. The Association Class "SUPAHasBooleanClauseDetail" . 101 322 6.9.3.1. SUPAHasBooleanClauseDetail Attributes ......... 101 323 6.10. The Abstract Class "SUPAECAComponent" .................. 102 324 6.10.1. SUPAECAComponent Attributes ....................... 102 325 6.10.1.1. The Attribute supaECACompIsTerm .............. 102 326 6.10.2. SUPAECAComponent Relationships .................... 102 327 6.11. The Concrete Class "SUPAPolicyEvent" ................... 103 328 6.11.1. SUPAPolicyEvent Attributes ........................ 103 329 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 103 330 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 103 331 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 103 332 6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 103 333 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 104 334 6.11.2. SUPAPolicyEvent Relationships ..................... 104 335 6.12. The Concrete Class "SUPAPolicyCondition" ............... 104 336 6.12.1. SUPAPolicyCondition Attributes .................... 105 337 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 105 338 6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 105 339 6.12.2. SUPAPolicyEvent Relationships ..................... 105 340 6.13. The Concrete Class "SUPAPolicyAction" .................. 106 341 6.13.1. SUPAPolicyAction Attributes ....................... 106 342 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 106 343 6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 107 344 6.13.2. SUPAPolicyAction Relationships .................... 107 346 7. Examples ..................................................... 107 347 8. Security Considerations ..................................... 107 348 9. IANA Considerations .......................................... 107 349 10. Contributors ................................................ 108 350 11. Acknowledgments ............................................. 108 351 12. References .................................................. 108 352 12.1. Normative References ................................... 108 353 12.2. Informative References ................................ 108 354 Authors' Addresses ............................................... 109 355 Appendix A. Brief Analyses of Previous Policy Work .............. 110 356 1. Overview 358 This document defines an information model for representing 359 policies using a common extensible framework that is independent 360 of language, protocol, repository, and the level of abstraction of 361 the content and meaning of a policy. This enables a common set of 362 concepts defined in this information model to be mapped into 363 different representations of policy (e.g., procedural, imperative, 364 and declarative). It also enables different data models that use 365 different languages, protocols, and repositories to optimize 366 their usage. The definition of common policy concepts also 367 provides better interoperability by ensuring that each data 368 model can share a set of common concepts, independent of its 369 level of detail or the language, protocol, and/or repository 370 that it is using. It is also independent of the target data 371 model that will be generated. 373 This version of the information model focuses on defining one 374 type of policy rule: the event-condition-action (ECA) policy rule. 375 Accordingly, this document defines two sets of model elements: 377 1. A framework for defining the concept of policy, 378 independent of how policy is represented or used; this is 379 called the SUPA Generic Policy Information Model (GPIM) 380 2. A framework for defining a policy model that uses the 381 event-condition-action (ECA) paradigm; this is called the 382 SUPA ECA Policy Rule Information Model (EPRIM), and extends 383 concepts from the GPIM. 385 The combination of the GPIM and the EPRIM provides an extensible 386 framework for defining policy that uses an event-condition-action 387 representation that is independent of data repository, data 388 definition language, query language, implementation language, and 389 protocol. 391 The Appendices describe how the structure of the GPIM defines a 392 set of generic concepts that enables other types of policies, such 393 as declarative (or "intent-based") policies, to be added later. 395 1.1. Introduction 397 Simplified Use of Policy Abstractions (SUPA) defines a technology- 398 independent neutral information model for creating high-level, 399 possibly network-wide policies as input and producing element 400 configurations (either whole or snippets) as output. SUPA addresses 401 the needs of operators, end-users, and application developers to 402 represent multiple types of ECA policy rules, such as for traffic 403 selection and configuration or security. These ECA policy rules may 404 vary in the level of abstraction to suit the needs of different 405 actors (e.g., end-users vs. administrators) [1], [10]. 407 Different constituencies of users would like to use terminology and 408 concepts that are familiar to each constituency. Rather than require 409 multiple software systems to be used for each constituency, a common 410 information model enables these different concepts and terms to be 411 mapped to elements in the information model. This facilitiates the 412 use of a single software system to generate data models for each 413 language. In the example shown in Figure 1 (which is a simplified 414 Policy Continuum [10]), each constituency uses different concepts 415 and terms (according to their skill sets and roles) to formulate 416 (ECA) policy rules that are useful for their job functions. A 417 unified information model is one way to build a consensual lexicon 418 that enables terms from one language to be mapped to terms of 419 another language. This approach enables the syntax of each language 420 to be modified appropriate to its user while keeping a common set 421 of semantics for all languages. This is shown in Figure 1. 423 +-------------------+ 424 | Information Model | 425 | and one or more +<------------------------+ 426 | Data Models | | 427 +-------------------+ | 428 | 429 +---------------------+ | 430 +---------------+ \| High-level Policies | \+-------------+ | 431 | Business User |----| Without Technical |----| Language #1 +<----+ 432 +---------------+ /| Terminology | /+-------------+ | 433 +---------------------+ | 434 | 435 +---------------------+ | 436 +---------------+ \| Policies That Use | \+-------------+ | 437 | Developer |----| Classes, Attributes,|----| Language #2 +<----+ 438 +---------------+ /| Relationships, ... | /+-------------+ | 439 +---------------------+ | 440 | 441 ... ... ... | 442 | 443 +---------------------+ | 444 +---------------+ \| Low-level Policies | \+-------------+ | 445 | Admin |----| with Technology- |----| Language #n +<----+ 446 +---------------+ /| Specific Terms in a | /+-------------+ 447 | Specific Language | 448 +---------------------+ 450 Figure 1. Different Constituencies Need Different Policies 452 More importantly, an information model defines concepts in a 453 uniform way, enabling formal mapping processes to be developed to 454 translate the information model to a set of data models. This 455 simplifies the process of constructing software to automate the 456 policy management process. It also simplifies the language 457 generation process, though that is beyond the scope of this 458 document. 460 This common framework takes the form of an information model that 461 is divided into one high-level module and one or more number of 462 lower-level modules. A lower-level module extends the higher-level 463 module into a new domain; each lower-level domain module can itself 464 be extended to model more granular domain-specific (but still 465 technology- and vendor-independent) concepts as necessary. 467 Conceptually, a set of model elements (e.g., classes, attributes, 468 constraints, and relationships) are used to define the Generic 469 Policy Information Model (GPIM); this module defines a common set of 470 policy concepts that are independent of the type of policy (e.g., 471 imperative, procedural, declarative, or otherwise). Then, any number 472 of additional modules can be derived from the GPIM; each additional 473 module MUST extend the GPIM to define a new type of policy rule by 474 adding to the GPIM. Each additoinal module MUST NOT alter any of 475 the model elements of the GPIM. The use of extensions preserves the 476 interoperability of this approach; if the base GPIM was modified, 477 then this would adversely compromise interoperability. 479 The SUPA ECA Policy Rule Information Model (EPRIM) extends the 480 GPIM to represent policy rules that use the Event-Condition-Action 481 (ECA) paradigm. 483 1.2. Changes Since Version -00 485 There are several changes in this version of this document 486 compared to the previous versions of this document. They are: 488 1) Rewrote parts of the Introduction. 489 2) Clarified how to extend the GPIM and EPRIM 490 3) Redesigned the SUPAPolicyVersionMetadataDef class 491 4) Added Fully Qualified Path Names where applicable 492 5) Removed Appendices B and C (declarative policies) 493 6) Fixed typos 495 2. Conventions Used in This Document 497 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 498 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 499 this document are to be interpreted as described in [RFC2119]. In 500 this document, these words will appear with that interpretation 501 only when in ALL CAPS. Lower case uses of these words are not to 502 be interpreted as carrying [RFC2119] significance. 504 3. Terminology 506 This section defines acronyms, terms, and symbology used in the 507 rest of this document. 509 3.1. Acronyms 511 CLI Command Line Interface 512 CRUD Create, Read, Update, Delete 513 CNF Conjunctive Normal Form 514 DNF Disjunctive Normal Form 515 ECA Event-Condition-Action 516 EPRIM (SUPA) ECA Policy Rule Information Model 517 GPIM (SUPA) Generic Policy Information Model 518 OAM&P Operations, Administration, Management, and Provisioning 519 OID Object IDentifier 520 SUPA Simplified Use of Policy Abstractions 521 TMF TeleManagent Forum (TM Forum) 522 UML Unified Modeling Language 523 URI Uniform Resource Identifier 524 YANG A data definition language for use with NETCONF 525 ZOOM Zero-touch Orchestration, Operations, and Management 526 (a TMF project that also works on information models) 528 3.2. Definitions 530 This section defines the terminology that is used in this document. 532 3.2.1. Core Terminology 534 The following subsections define the terms "information model" and 535 "data model", as well as "container" and "policy container". 537 3.2.1.1. Information Model 539 An information model is a representation of concepts of interest 540 to an environment in a form that is independent of data repository, 541 data definition language, query language, implementation language, 542 and protocol. 544 Note: this definition is more specific than that of [RFC3198], so 545 as to focus on the properties of information models. That definition 546 was: "An abstraction and representation of the entities in a managed 547 environment, their properties, attributes and operations, and the 548 way that they relate to each other. It is independent of any 549 specific repository, software usage, protocol, or platform." 551 3.2.1.2. Data Model 553 A data model is a representation of concepts of interest to an 554 environment in a form that is dependent on data repository, data 555 definition language, query language, implementation language, and/or 556 protocol (typically, but not necessarily, all five). 558 Note: this definition is more specific than that of [RFC3198], so 559 as to focus on the properties of data models that are generated 560 from information models. That definition was: "A mapping of the 561 contents of an information model into a form that is specific to a 562 particular type of data store or repository." 564 3.2.1.3. Class 566 A class is a set of objects that exhibit a common set of 567 characteristics and behavior. 569 3.2.1.3.1. Abstract Class 571 An abstract class is a class that cannot be directly instantiated. 572 It MAY have abstract or concrete subclasses. It is denoted with a 573 capital A (for abstract) near the top-left side of the class. 575 3.2.1.3.2. Concrete Class 577 A concrete class is a class that can be directly instantiated. Note 578 that classes are either abstract or concrete. In addition, once a 579 class has been defined as concrete in the hierarchy, all of its 580 subclasses MUST also be concrete. It is denoted with a capital C 581 (for concrete) near the top-left side of the class. 583 3.2.1.4. Container 585 A container is an object whose instances may contain zero or more 586 additional objects, including container objects. A container 587 provides storage, query, and retrieval of its contained objects 588 in a well-known, organized way. 590 3.2.1.5. PolicyContainer 592 In this document, a PolicyContainer is a special type of container 593 that provides at least the following three functions: 595 1. It uses metadata to define how its content is interpreted 596 2. It separates the content of the policy from the 597 representation of the policy 598 3. It provides a convenient control point for OAM&P operations 600 The combination of these three functions enables a PolicyContainer 601 to define the behavior of how its constituent components will be 602 accessed, queried, stored, retrieved, and how they operate. 604 This document does NOT define a specific data type to implementation 605 a PolicyContainer, as many different types of data types can be 606 used. However, the data type chosen SHOULD NOT allow duplicate 607 members in the PolicyContainer. In addition, order is irrelevant, 608 since priority will override any initial order of the members of 609 this PolicyContainer. 611 3.2.2. Policy Terminology 613 The following terms define different policy concepts used in the 614 SUPA Generic Policy Information Model (GPIM). Note that the 615 prefix "SUPA" is used for all classes and relationships defined 616 in this model to ensure name uniqueness. Similarly, the prefix 617 "supa" is defined for all SUPA class attributes. 619 3.2.2.1. SUPAPolicyObject 621 A SUPAPolicyObject is the root of the GPIM class hierarchy. It is 622 an abstract class that all classes inherit from, except the 623 SUPAPolicyMetadata class and its subclasses. 625 3.2.2.2. SUPAPolicy 627 A SUPAPolicy is, in this version of this document, an ECA policy 628 rule that is a type of PolicyContainer. The PolicyContainer MUST 629 contain an ECA policy rule, SHOULD contain one or more 630 SUPAPolicyMetadata objects, and MAY contain other elements that 631 define the semantics of the policy rule. Policies are generically 632 defined as a means to monitor and control the changing and/or 633 maintaining of the state of one or more managed objects [1]. In 634 this context, "manage" means that one or more of the following six 635 fundamental operations are supported: create, read, write, delete, 636 start, and stop) [16]. 638 3.2.2.3. SUPAPolicyClause 640 A SUPAPolicyClause is an abstract class. Its subclasses define 641 different types of clauses that are used to create the content 642 for different types of SUPAPolicies. 644 For example, the SUPABooleanClause subclass models the content 645 of a SUPAPolicy as a Boolean clause, where each Boolean clause 646 is made up of a set of reusable objects. In contrast, a 647 SUPAEncodedClause encodes the entire clause as a set of 648 attributes. All types of SUPAPolicies MUST use one or more 649 SUPAPolicyClauses to construct a SUPAPolicy. 651 3.2.2.4. SUPAECAPolicyRule 653 An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an 654 abstract class that is a type of PolicyContainer. It represents 655 a policy rule as a three-tuple, consisting of an event, a 656 condition, and an action clause. In an information model, this 657 takes the form of three different aggregations, one for each 658 clause. Each clause MUST be represented by at least one 659 SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain 660 zero or more SUPAPolicySources, zero or more SUPAPolicyTargets, 661 and zero or more SUPAPolicyMetadata objects. Note that for this 662 version of this document, ECA Policy Rules are the **only** 663 types of Policies that are defined. 665 3.2.2.5. SUPAMetadata 667 Metadata is, literally, data about data. SUPAMetadata is an 668 abstract class that contains prescriptive and/or descriptive 669 information about the object(s) to which it is attached. While 670 metadata can be attached to any information model element, this 671 document only considers metadata attached to classes and 672 relationships. 674 When defined in an information model, each instance of the 675 SUPAMetadata class MUST have its own aggregation relationship 676 with the set of objects that it applies to. However, a data model 677 MAY map these definitions to a more efficient form (e.g., 678 flattening the object instances into a single object instance). 680 3.2.2.6. SUPAPolicyTarget 682 SUPAPolicyTarget is an abstract class that defines a set of 683 managed objects that may be affected by the actions of a 684 SUPAPolicyClause. A SUPAPolicyTarget may use one or more 685 mechanisms to identify the set of managed objects that it 686 affects; examples include OIDs and URIs. 688 When defined in an information model, each instance of the 689 SUPAPolicyTarget class MUST have its own aggregation 690 relationship with each SUPAPolicy that uses it. However, a 691 data model MAY map these definitions to a more efficient form 692 (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and 693 SUPAPolicy object instances into a single object instance). 695 3.2.2.7. SUPAPolicySource 697 SUPAPolicySource is an abstract class that defines a set of 698 managed objects that authored this SUPAPolicyClause. This is 699 required for auditability and authorization policies, as well 700 as some forms of deontic and alethic logic. 702 A SUPAPolicySource may use one or more mechanisms to identify the 703 set of managed objects that authored it; examples include OIDs and 704 URIs. Specifically, policy CRUD MUST be subject to authentication 705 and authorization, and MUST be auditable. Note that the mechanisms 706 for doing these three operations are currently not included, and 707 are for further discussion. 709 When defined in an information model, each instance of the 710 SUPAPolicySource class MUST have its own aggregation relationship 711 with each SUPAPolicy that uses it. However, a data model MAY map 712 these definitions to a more efficient form (e.g., flattening the 713 SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances 714 into a single object instance). 716 3.2.3. Modeling Terminology 718 The following terms define different types of relationships used 719 in the information models of the SUPA Generic Policy Information 720 Model (GPIM). 722 3.2.3.1. Inheritance 724 Inheritance makes an entity at a lower level of abstraction (e.g., 725 the subclass) a type of an entity at a higher level of abstraction 726 (e.g., the superclass). Any attributes and relationships that are 727 defined for the superclass are also defined for the subclass. 728 However, a subclass does NOT change the characteristics or behavior 729 of the attributes or relationships of the superclass that it 730 inherits from. Formally, this is called the Liskov Substitution 731 Principle [7]. This principle is one of the key characteristics 732 that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. 734 A subclass MAY add new attributes and relationships that refine 735 the characteristics and/or behavior of it compared to its 736 superclass. A subclass MUST NOT change inherited attributes or 737 relationships. 739 3.2.3.2. Relationship 741 A relationship is a generic term that represents how a first set 742 of entities interact with a second set of entities. A recursive 743 relationship sets the first and second entity to the same entity. 744 There are three basic types of relationships, as defined in the 745 subsections below: associations, aggregations, and compositions. 747 A subclass MUST NOT change the multiplicity (see section 3.2.3.7) 748 of a relationship that it inherits. A subclass MUST NOT change any 749 attributes of a relation that it inherits that is realized using 750 an association class (see section 3.2.3.6). 752 3.2.3.3. Association 754 An association represents a generic dependency between a first 755 and a second set of entities. In an information model, an 756 association MAY be represented as a class. 758 3.2.3.4. Aggregation 760 An aggregation is a stronger type (i.e., more restricted 761 semantically) of association, and represents a whole-part 762 dependency between a first and a second set of entities. Three 763 objects are defined by an aggregation: the first entity, the 764 second entity, and a new third entity that represents the 765 combination of the first and second entities. 767 The entity owning the aggregation is referred to as the 768 "aggregate", and the entity that is aggregated is referred to as 769 the "part". In an information model, an aggregation MAY be 770 represented as a class. 772 3.2.3.5. Composition 774 A composition is a stronger type (i.e., more restricted 775 semantically) of aggregation, and represents a whole-part 776 dependency with two important behaviors. First, an instance of the 777 part is included in at most one instance of the aggregate at a 778 time. Second, any action performed on the composite entity (i.e., 779 the aggregate) is propagated to its constituent part objects. 780 For example, if the composite entity is deleted, then all of its 781 constituent part entities are also deleted. This is not true of 782 aggregations or associations - in both, only the entity being 783 deleted is actually removed, and the other entities are unaffected. 784 In an information model, a composition MAY be represented as 785 a class. 787 3.2.3.6. Association Class 789 A relationship may be implemented as an association class. This is 790 used to define the relationship as having its own set of features. 791 (Note: in this document, all relationships are implemented as 792 association classes for consistency and to simplify implementation.) 793 More specifically, if the relationship is implemented as an 794 association class, then the attributes of the association class, as 795 well as other relationships that the association class participates 796 in, may be used to define the semantics of the relationship. If the 797 relationship is not implemented as an association class, then no 798 additional semantics (beyond those defined by the type of the 799 relationship) are expressed by the relationship. 801 3.2.3.7. Multiplicity 803 A specification of the range of allowable cardinalities that a set 804 of entities may assume. This is always a pair of ranges, such as 805 1 - 1 or 0..n - 2..5. 807 3.2.3.8. Navigability 809 A relationship may restrict one object from accessing the other 810 object. This document defines two choices: 812 1. Each object is navigable by the other, which is indicated 813 by NOT providing any additional symbology, or 814 2. An object A can navigate to object B, but object B cannot 815 navigate to object A. This is indicated by an open-headed 816 arrow pointing to the object that cannot navigate to the 817 other object. An example is shown below: 819 +---------+ 3..4 +---------+ 820 | | 1..2 \| | 821 | Class A |--------------| Class B | 822 | | /| | 823 +---------+ +---------+ 825 The above figure shows a navigability restriction. Class A can 826 navigate to Class B, but Class B cannot navigate to Class A. This is 827 a mandatory association, since none of the multiplicities contain a 828 '0'. This association reads as follows: 830 Class A depends on 3 to 4 instances of Class B, and 831 Class B depends on 1 to 2 instances of Class A. 833 3.3. Symbology 835 The following symbology is used in this document. 837 3.3.1. Inheritance 839 Inheritance: a subclass inherits the attributes and relationships 840 of its superclass, as shown below: 842 +------------+ 843 | Superclass | 844 +------+-----+ 845 / \ 846 I 847 I 848 I 849 +------+-----+ 850 | Subclass | 851 +------------+ 853 3.3.2. Association 855 Association: Class B depends on Class A, as shown below: 857 +---------+ +---------+ 858 +---------+ +---------+ | | \| | 859 | Class A |------| Class B | | Class A |------| Class B | 860 +---------+ +---------+ | | /| | 861 +---------+ +---------+ 863 association with no association with 864 navigability restrictions navigability restrictions 866 3.3.3. Aggregation 868 Aggregation: Class B is the part, Class A is the aggregate, 869 as shown below: 871 +---------+ +---------+ +---------+ 872 | |/ \ +---------+ | |/ \ \| | 873 | Class A | A ---| Class B | | Class A | A ------| Class B | 874 | |\ / +---------+ | |\ / /| | 875 +---------+ +---------+ +---------+ 877 aggregation with no aggregation with 878 navigability restrictions navigability restrictions 880 3.3.4. Composition 882 Composition: Class B is the part, Class A is the composite, 883 as shown below: 885 +---------+ +---------+ +---------+ 886 | |/ \ +---------+ | |/ \ \| | 887 | Class A | C ---| Class B | | Class A | C ------| Class B | 888 | |\ / +---------+ | |\ / /| | 889 +---------+ +---------+ +---------+ 891 composition with no composition with 892 navigability restrictions navigability restrictions 894 3.3.5. Association Class 896 Association Class: Class C is the association class implementing 897 the relationship D between classes A and B 898 +---------+ +---------+ 899 | Class A |----+-----| Class B | 900 +---------+ ^ +---------+ 901 | 902 | 903 +----------+----------+ 904 | Association Class C | 905 +---------------------+ 907 3.3.6. Abstract vs. Concrete Classes 909 In UML, abstract classes are denoted with their name in italics. 910 For this draft, a capital 'A' will be placed at either the top 911 left or right corner of the class to signify that the class is 912 abstract. Similarly, a captial 'C' will be placed in the same 913 location to represent a concrete class. This is shown below. 915 A C 916 +---------+ +---------+ 917 | Class A | | Class B | 918 +---------+ +---------+ 920 An Abstract Class A Concrete Class 922 4. Policy Abstraction Architecture 924 This section describes the motivation for the policy abstractions 925 that are used in SUPA. The following abstractions are provided: 927 o The GPIM defines a technology-neutral information model that 928 can express the concept of Policy. 929 o All classes, except for SUPAPolicyMetadata, inherit from 930 SUPAPolicyObject, or one of its subclasses. 931 o SUPAPolicyObject and SUPAPolicyMetadata are designed to 932 inherit from classes in another model; the GPIM does not 933 define an "all-encompassing" model. 934 o This version of this document restricts the expression of 935 Policy to a set of event-condition-action clauses. 936 o Each clause is defined as a Boolean expression, and MAY 937 also be defined as a reusable object. 938 o Clauses may be combined to form more complex Boolean 939 expressions. 940 o The purpose of the GPIM is to enable different policies that 941 have fundamentally different representations to share common 942 model elements. Policy statements, which are implemented as 943 instances of the SUPAPolicyClause class, separates the content 944 of a Policy from its representation. This is supported by: 945 o All policy rules (of which SUPAECAPolicyRule is the 946 first example of a concrete class) are derived from 947 the SUPAPolicyStructure class. 948 o All objects that are components of policy rules are 949 derived from the SUPAPolicyComponentStructure class. 950 o A SUPAPolicy MUST contain at least one SUPAPolicyClause. 951 o A SUPAPolicy MAY specify one or more SUPAPolicyTarget, 952 SUPAPolicySource, and SUPAPolicyMetadata objects to 953 augment the semantics of the SUPAPolicy 954 o A SUPAPolicyClause has two subclasses: 955 o A SUPABooleanClause, which is used to build 956 SUPAECAPolicyRules from reusable objects. 957 o A SUPAEncodedClause, which is used for using 958 attributes instead of objects to construct a 959 SUPAECAPolicyRule. 960 o A SUPAECAPolicyRule defines the set of events and conditions 961 that are responsible for executing its actions; it MUST have 962 at least one event clause, at least one condition clause, and 963 at least one action clause. 964 o The action(s) of a SUPAECAPolicyRule are ONLY executed 965 if both the event and condition clauses evaluate to TRUE 966 o A SUPAPolicyAction MAY invoke another SUPAECAPolicyRule 967 (see section 6.13). 968 o SUPAMetadata MAY be defined for any SUPAPolicyObject class. 969 o SUPAMetadata MAY be prescriptive and/or descriptive in nature. 971 4.1. Motivation 973 The power of policy management is its applicability to many 974 different types of systems. There are many different actors that 975 can use a policy management system, including end-users, operators, 976 application developers, and administrators. Each of these 977 constituencies have different concepts and skills, and use 978 different terminology. For example, an operator may want to express 979 an operational rule that states that only Platinum and Gold users 980 can use streaming multimedia applications. As a second example, a 981 network administrator may want to define a more concrete policy 982 rule that looks at the number of dropped packets and, if that 983 number exceeds a programmable threshold, changes the queuing and 984 dropping algorithms used. 986 SUPA may be used to define other types of policies, such as for 987 systems and operations management; an example is: "All routers and 988 switches must have password login disabled". See section 3 of [8] 989 for additional declarative and ECA policy examples. 991 All of the above examples are commonly referred to as "policy 992 rules", but they take very different forms, since they are at very 993 different levels of abstraction and typically authored by 994 different actors. The first was very abstract, and did not contain 995 any technology-specific terms, while the second was more concrete, 996 and likely used technical terms of a general (e.g., IP address 997 range, port numbers) as well as a vendor-specific nature (e.g., 998 specific queuing, dropping, and/or scheduling algorithms 999 implemented in a particular device). The third restricted the type 1000 of login that was permissible for certain types of devices in the 1001 environment. 1003 Note that the first two policy rules could directly affect each 1004 other. For example, Gold and Platinum users might need different 1005 device configurations to give the proper QoS markings to their 1006 streaming multimedia traffic. This is very difficult to do if a 1007 common policy model does not exist, especially if the two policies 1008 are authored by different actors that use different terminology 1009 and have different skill sets. More importantly, the users of 1010 these two policies likely have different job responsibilities. 1011 They may have no idea of the concepts used in each policy. Yet, 1012 their policies need to interact in order for the business to 1013 provide the desired service. This again underscores the need for 1014 a common policy framework. 1016 Certain types of policy rules (e.g., ECA) may express actions, or 1017 other types of operations, that contradict each other. SUPA 1018 provides a rich object model that can be used to support language 1019 definitions that can find and resolve such problems. 1021 4.2. SUPA Approach 1023 The purpose of the SUPA Generic Policy Information Model (GPIM) is 1024 to define a common framework for expressing policies at different 1025 levels of abstraction. SUPA uses the GPIM as a common vocabulary 1026 for representing policy concepts that are independent of language, 1027 protocol, repository, and level of abstraction. This enables 1028 different actors to author and use policies at different levels of 1029 abstraction. This forms a policy continuum [1] [2], where more 1030 abstract policies can be translated into more concrete policies, 1031 and vice-versa. 1033 Most systems define the notion of a policy as a single entity. 1034 This assumes that all users of policy have the same terminology, 1035 and use policy at the same level of abstraction. This is rarely, 1036 if ever, true in modern systems. The policy continuum defines a 1037 set of views (much like RM-ODP's viewpoints [9]) that are each 1038 optimized for a user playing a specific role. SUPA defines the 1039 GPIM as a standard vocabulary and set of concepts that enable 1040 different actors to use different formulations of policy. This 1041 corresponds to the different levels in the policy continuum, and 1042 as such, can make use of previous experience in this area. 1044 It may be necessary to translate a Policy from a general to a more 1045 specific form (while keeping the abstraction level the same). For 1046 example, the declarative policy "Every network attached to a VM 1047 must be a private network owned by someone in the same group as 1048 the owner of the VM" may be translated to more formal form (e.g., 1049 Datalog (as in OpenStack Congress). It may also be necessary to 1050 translate a Policy to a different level of abstraction. For 1051 example, the previous Policy may need to be translated to a form 1052 that network devices can process directly. This requires a common 1053 framework for expressing policies that is independent of the level 1054 of abstraction that a Policy uses. 1056 4.3. SUPA Generic Policy Information Model Overview 1058 Figure 2 illustrates the approach for representing policy rules 1059 in SUPA. The top two layers are defined in this document; the 1060 bottom layer (Data Models) are defined in separate documents. 1061 Conceptually, the GPIM defines a set of objects that define the 1062 key elements of a Policy independent of how it is represented or 1063 its content. As will be shown, there is a significant difference 1064 between SUPAECAPolicyRules (see Section 6) and other types of 1065 policies (see Section 7). In principle, other types of SUPAPolicies 1066 could be defined, but the current charter is restricted to using 1067 only event-condition-action SUPAPolicies as exemplars. 1069 Note: the GPIM MAY be used without the EPRIM. However, in order to 1070 use the EPRIM, the GPIM MUST also be used. 1072 +----------------------------------------------+ 1073 | SUPA Generic Policy Information Model (GPIM) | 1074 +----------------------+-----------------------+ 1075 / \ 1076 | 1077 | 1078 +-----------------+--------------+ 1079 | | 1080 | | 1081 +-----------+---------------+ +-------------+-------------+ 1082 | SUPAECAPolicyRule | | Other Policy Models that | 1083 | Information Model (EPRIM) | | are Derived from the GPIM | 1084 +-----------+---------------+ +-------------+-------------+ 1085 / \ / \ 1086 | | 1087 | | 1088 +-----------+-----------+ +-----------+------------+ 1089 | ECAPolicyRule | | Other Types of | 1090 | Data Model | | Data Models | 1091 +-----------------------+ +------------------------+ 1093 Figure 2. Overview of SUPA Policy Rule Abstractions 1095 This draft defines the GPIM and EPRIM. This draft further assumes 1096 that the SUPA Information Model is made up of either the GPIM or the 1097 combination of the GPIM and the EPRIM. Extensions to both the GPIM 1098 and the EPRIM can be made as long as these extensions do not 1099 conflict with the content and structure defined in the GPIM and 1100 EPRIM. If the GPIM and EPRIM are part of another information model, 1101 then they should collectively still define a single information 1102 model. The GPIM defines the following concepts: 1104 o A class defining the top of the GPIM class hierarchy, called 1105 SUPAPolicyObject 1106 o Four subclasses of SUPAPolicyObject, representing: 1107 o the top of the Policy hierarchy, called 1108 SUPAPolicyStructure 1109 o the top of the Policy component hierarchy, called 1110 SUPAPolicyComponentStructure 1111 o PolicySource 1112 o PolicyTarget 1114 The SUPAPolicyStructure class is the superclass for all types of 1115 Policies (e.g., imperative, declarative, and others). This 1116 document is currently limited to imperative (e.g., ECA) policies. 1117 However, care has been taken to ensure that the attributes and 1118 relationships of the SUPAPolicyStructure class are extensible, 1119 and can be used for more types of policies than just ECA policies. 1121 This yields the following high-level structure: 1123 A 1124 +------------------+ 1125 | SUPAPolicyObject | 1126 +--------+---------+ 1127 / \ 1128 I 1129 I 1130 +----------------+--------------------+ 1131 I I I 1132 A I I A I 1133 +--------+------------+ I +------------+-----------------+ 1134 | SUPAPolicyStructure | I | SUPAPolicyComponentStructure | 1135 +----+----------------+ I +------------+-----------------+ 1136 / \ I / \ 1137 I +--------+----+ I 1138 I I I I 1139 I C I I I 1140 I +-------+----------+ I I 1141 I | SUPAPolicySource | I I 1142 I +------------------+ I I 1143 I I I 1144 I +-------------+ I 1145 I I +-----+-------+ 1146 I C I I I 1147 I +-------+----------+ A I I 1148 I | SUPAPolicyTarget | +--------+---------+ I 1149 I +------------------+ | SUPAPolicyClause | I 1150 A I +------------------+ I 1151 +-----+------------+ I 1152 | SUPAECAPolicyRule| A I 1153 +------------------+ +--------------------+---------+ 1154 | SUPAPolicyComponentDecorator | 1155 +------------------------------+ 1157 Figure 3. Functional View of the Top-Level GPIM 1159 Note that all classes except the SUPAPolicySource and the 1160 SUPAPolicyTarget classes are defined as abstract. This provides 1161 more freedom for the data modeler in implementing the data model. 1162 For example, if the data model uses an object-oriented language, 1163 such as Java, then the above structure enables all of the abstract 1164 classes to be collapsed into a single concrete class. If this is 1165 done, attributes as well as relationships are inherited. 1167 4.3.1. SUPAPolicyObject 1169 A SUPAPolicyObject serves as a single root of the SUPA system 1170 (i.e., all other classes in the model are subclasses of the 1171 SUPAPolicyObject class) except for the Metadata objects, which are 1172 in a separate class hierarchy. This simplifies code generation and 1173 reusability. It also enables SUPAPolicyMetadata objects to be 1174 attached to any appropriate subclass of SUPAPolicyObject. 1176 4.3.2. SUPAPolicyStructure 1178 SUPAPolicyStructure is an abstract superclass that is the base 1179 class for defining different types of policies (however, in this 1180 version of this document, only ECA policy rules are modeled). It 1181 serves as a convenient aggregation point to define atomic (i.e., 1182 individual policies that can be used independently) and composite 1183 (i.e., hierarchies of policies) SUPAPolicies; it also enables 1184 PolicySources and/or PolicyTargets to be associated with a given 1185 set of Policies. 1187 SUPAPolicies are defined as either a stand-alone PolicyContainer 1188 or a hierarchy of PolicyContainers. A PolicyContainer specifies 1189 the structure, content, and optionally, source, target, and 1190 metadata information for a SUPAPolicy. This is implemented by the 1191 subclasses of SUPAPolicyStructure. For example, the composite 1192 pattern is used to create two subclasses of the SUPAECAPolicyRule 1193 class; SUPAECAPolicyRuleAtomic is used for stand-alone policies, 1194 and SUPAECAPolicyRuleComposite is used to build hierarchies of 1195 policies. 1197 This document defines a SUPAPolicy as an ECA Policy Rule, though 1198 the GPIM enables other types of policies to be defined and used 1199 with an ECA policy rule. The GPIM model is used in [2] and [5], 1200 along with extensions that allow [2] and [5] to define multiple 1201 types of policies that are derived from the GPIM. They also allow 1202 different combinations of different types of policy rules to be 1203 used with each other. Most previous work cannot define different 1204 types of policy rules; please see Appendix A for a comparison to 1205 previous work. 1207 4.3.3. SUPAPolicyComponentStructure 1209 SUPAPolicyComponentStructure is an abstract superclass that is the 1210 base class for defining components of different types of policies. 1211 SUPAPolicyStructure subclasses define the structure of a policy, 1212 while SUPAPolicyComponentStructure subclasses define the content 1213 that is contained in the structure of a policy. For example, a 1214 SUPAECAPolicyRule is an imperative policy rule, and defines its 1215 structure; its event, condition, and action clauses are populated 1216 by SUPAPolicyComponentStructure subclasses. The strength of this 1217 design is that different types of policies (e.g., imperative and 1218 declarative policies) can be represented using a common set of 1219 policy components. 1221 Please see Appendix for a comparison to previous work. 1223 4.3.4. SUPAPolicyClause 1225 All policies derived from the GPIM are made up of one or more 1226 SUPAPolicyClauses, which define the content of the Policy. 1227 This enables a Policy of one type (e.g., ECA) to invoke Policies 1228 of the same or different types. SUPAPolicyClause is an abstract 1229 class, and serves as a convenient aggregation point for assembling 1230 other objects that make up a SUPAPolicyClause. 1232 The GPIM defines a single concrete subclass of SUPAPolicyClause, 1233 called SUPAEncodedClause. This is a generic clause, and can be 1234 used by any type of Policy in a stand-alone fashion. It can also 1235 be used in conjunction with other SUPAPolicyClauses. The EPRIM 1236 also defines a subclass of SUPAPolicyClause; see section 6.7). 1238 The structure of the GPIM is meant to provide an extensible 1239 framework for defining different types of policies. This is 1240 demonstrated by the EPRIM (see section 6) and the LSIM (see the 1241 Appendices) that each define new subclasses of SUPAPolicyClause 1242 (i.e., SUPABooleanClause and SUPALogicClause, respectively) 1243 without defining new classes that have no GPIM superclass. 1245 A SUPAPolicyClause is defined as an object. Therefore, clauses and 1246 sets of clauses are objects, which promotes reusability. 1248 4.3.5. SUPAPolicyComponentDecorator 1250 One of the problems in building a policy model is the tendency to 1251 have a multitude of classes, and hence object instances, to 1252 represent different combinations of policy events, conditions, and 1253 actions. This can lead to class and/or relationship explosion. 1254 Please see Appendix A for a comparison to previous work. 1256 SUPAPolicyClauses are constructed using the Decorator Pattern 1257 [11]. This is a design pattern that enables behavior to be 1258 selectively added to an individual object, either statically or 1259 dynamically, without affecting the behavior of other objects from 1260 the same class. The decorator pattern uses composition, instead of 1261 inheritance, to avoid class and relationship explosion. The 1262 decorator pattern also enable new objects to be composed from 1263 parts or all of existing objects without affecting the existing 1264 objects. 1266 This enables the resulting SUPAPolicyClause to be constructed 1267 completely from objects in the SUPA information model. This 1268 facilitates the construction of policies at runtime by a machine. 1269 This is also true of [2] and [5]; however, this is NOT true of 1270 most other models. Please see Appendix A for a comparison to 1271 previous work. 1273 SUPAPolicyComponentDecorator defines four types of objects that 1274 can be used to form a SUPAPolicyClause. Each object may be used 1275 with all other objects, if desired. The first three are defined 1276 in the GPIM, with the last defined in the EPRIM. The objects are: 1278 o SUPAPolicyTerm, which enables a clause to be defined in a 1279 canonical {variable, operator, value} form 1280 o SUPAGenericDecoratedComponent, which enabled a custom object 1281 to be defined and then used in a SUPAPolicyClause 1282 o SUPAPolicyCollection, which enables a collection of objects 1283 to be gathered together and associated with all or a portion 1284 of a SUPAPolicyClause 1285 o SUPAECAComponent, which defines Events, Conditions, and 1286 Actions as reusable objects 1288 This approach facilitates the machine-driven construction of 1289 policies. Note that this is completely optional; policies do not 1290 have to use these constructs. 1292 4.3.6. SUPAPolicyTarget 1294 A SUPAPolicyTarget is a set of managed entities that a SUPAPolicy 1295 is applied to. A managed entity can only be designated a 1296 SUPAPolicyTarget if it can process actions from a SUPAPolicy. 1298 A managed object may not be in a state that enables management 1299 operations to be performed on it. Furthermore, the policy-based 1300 management system SHOULD ensure that the management entity 1301 performing the management operations has the proper permissions to 1302 perform the management operations. The design of the 1303 SUPAPolicyTarget addresses both of these criteria. 1305 4.3.7. SUPAPolicySource 1307 A SUPAPolicySource is a set of managed entities that authored, or 1308 are otherwise responsible for, this SUPAPolicy. Note that a 1309 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 1310 primary use is for auditability and the implementation of deontic 1311 and/or alethic logic. 1313 4.4. The Design of the GPIM 1315 This section describes the overall design of the GPIM. 1317 The GPIM defines a policy as a type of PolicyContainer. For this 1318 version, only ECA Policy Rules will be described. However, it 1319 should be noted that the mechanism described is applicable to 1320 other types of policies (e.g., declarative) as well. 1322 4.4.1. Structure of Policies 1324 Recall that a PolicyContainer was defined as a special type of 1325 container that provides at least the following three functions: 1327 1. It uses metadata to define how its content is described 1328 and/or prescribed 1329 2. It separates the content of the policy from the 1330 representation of the policy 1331 3. It provides a convenient control point for OAMP operations. 1333 The first requirement is provided by the ability for any subclass 1334 of Policy (the root of the information model) to aggregate one or 1335 more concrete instances of a SUPAPolicyMetadata class. This is 1336 explained in detail in section 5.2.2. 1338 The second requirement is met by representing an ECA Policy as 1339 having two parts: (1) a rule part and (2) components that make up 1340 the rule. Since functional and declarative policies are not, 1341 strictly speaking, "rules", the former is named PolicyStructure, 1342 while the latter is named PolicyComponentStructure. 1344 The third requirement is met by the concrete subclasses of 1345 PolicyStructure. Since they are PolicyContainers, they are made 1346 up of the SUPAECAPolicyRule, its commponents, and any metadata 1347 that applies to the PolicyContainer, the SUPAECAPolicyRule, and.or 1348 any components of the SUPAECAPolicyRule. This provides optional 1349 low-level control over any part of the SUPAECAPolicyRule. 1351 The above requirements result in the design shown in Figure 4. 1353 A SUPAHasPolicyMetadata A 1354 +------------------+/ \ \+--------------------+ 1355 | SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata | 1356 +---------+--------+\ / /+--------------------+ 1357 / \ 0..n 0..n 1358 I 1359 I 1360 +------+------------------------------------+ 1361 I I 1362 A I A I 1363 +--------+------------+ +------------------+-----------+ 1364 | SUPAPolicyStructure | | SUPAPolicyComponentStructure | 1365 +--------+------------+ +-------------+----------------+ 1366 / \ / \ 1367 I I 1368 I I 1369 (subclasses representing (subclasses representing 1370 different types of policies) different policy components) 1372 Figure 4. Structure of a Policy 1374 Note that aggregation in Figure 4 (named SUPAHasPolicyMetadata) 1375 is realized as an association class, in order to manage which set 1376 of Metadata can be aggregated by which SUPAPolicyObject. The 1377 combination of these three functions enables a PolicyContainer 1378 to define the behavior of how its constituent components will be 1379 accessed, queried, stored, retrieved, and how they operate. 1381 It is often necessary to construct groups of policies. The GPIM 1382 follows [2] and [5], and uses the composite pattern [11] to 1383 implement this functionality, as shown in Figure 5 below. There 1384 are a number of advantages to using the composite pattern over a 1385 simple relationship, as detailed in [11]. 1387 Figure 5 shows that SUPAPolicyStructure has a single subclass, 1388 called SUPAECAPolicyRule. Note, however, that other types of 1389 policies, such as declarative policies, can be defined as 1390 subclasses of SUPAPolicyStructure in the future. 1392 A 1393 +---------------------+ 1394 | SUPAPolicyStructure | 1395 +--------+------------+ 1396 / \ 1397 I 1398 I 1399 +---------------+----------------+ 1400 I I 1401 C I A I 1402 +----------------+---------------+ +-----------+-----------+ 1403 | Future Subclasses to Represent | | SUPAECAPolicyRule | 1404 | Represent Different Policies | +-----------------------+ 1405 +--------------------------------+ 1407 Figure 5. The Composite Pattern Applied to SUPAPolicyStructure 1409 4.4.2. Representing an ECA Policy Rule 1411 An ECA policy rule is a 3-tuple, which is made up of an event 1412 clause, a condition clause, and an action clause. Each of these 1413 three types of clauses may in turn be made up of a Boolean 1414 combination of clauses of that type. Each clause may be viewed as 1415 a predicate, as it provides a TRUE or FALSE output. The canonical 1416 form of a clause is a 3-tuple of the form "variable operator value", 1417 and can be made into more complex Boolean expressions. For example, 1418 the SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two 1419 clauses, "(A AND B)" and "(C OR D)", that are combined together 1420 using the operators OR and NOT. 1422 A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract 1423 subclass of SUPAPolicyStructure. 1425 A A 1426 +---------------------------+ +------------------+ 1427 | SUPAPolicyStructure | | SUPAPolicyClause | 1428 +---------+---------+-------+ +--------+----+----+ 1429 / \ / \ 0..1 1..n / \ / \ 1430 I A | I 1431 I \ / | I 1432 I | | I 1433 I | SUPAHasPolicyClause | I 1434 I +------------------------+ I 1435 A I A I 1436 +------+------------+ +----------+-------+ 1437 | SUPAECAPolicyRule | | SUPAPolicyClause | 1438 +-------------------+ +------------------+ 1440 Figure 6. SUPAECAPolicyRule Aggregating SUPAPolicyClauses 1442 Note that the aggregation SUPAHasPolicyClause in Figure 6 is 1443 realized as an association class, in order to manage which set 1444 of SUPAPolicyClauses can be aggregated by which set of 1445 SUPAECAPolicyRules. This aggregation is defined at the 1446 SUPAPolicyStructure level, and not at the lower level of 1447 SUPAECAPolicyRule, so that non-ECA policies can also use this 1448 aggregation. 1450 Since a SUPAECAPolicyRule consists of three SUPAPolicyClauses, 1451 at least three separate instances of the SUPAHasPolicyClause 1452 aggregation are instantiated in order to make a complete 1453 SUPAECAPolicyRule, as shown in Figure 7. 1455 A A 1456 +-------------------+ +--------------------+ 1457 | SUPAECAPolicyRule | | SUPAPolicyClause | 1458 +--+----+----+------+ +-------+----+----+--+ 1459 / \ / \ / \ 1..n 0..n / \ / \ / \ 1460 A A A | | | 1461 \ / \ / \ / | | | 1462 | | | | | | 1463 | | | SUPAHasPolicyClause #1 | | | 1464 | | +------------------------------+ | | 1465 | | | | 1466 | | SUPAHasPolicyClause #2 | | 1467 | +----------------------------------------+ | 1468 | | 1469 | SUPAHasPolicyClause #3 | 1470 +--------------------------------------------------+ 1472 Figure 7. Instantiating a SUPAECAPolicyRule, part 1 1474 In figure 7, SUPAECAPolicyRule is shown as "owning" these three 1475 aggregations, since it inherits them from its superclass 1476 (SUPAPolicyStructure). The three aggregations represent the 1477 event, condition, and action clauses of a SUPAECAPolicyRule. 1478 Note that each of these clauses MAY consist of one or more 1479 SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist 1480 of one or more predicates. In this way, complex event, condition, 1481 and action clauses, which are combinations of Boolean expressions 1482 that form a logical predicate) are supported, without having to 1483 define additonal objects (as is done in previous work; please 1484 see Appendix A for a comparison to previous work. 1486 The multiplicity of the SUPAHasPolicyClause aggregation is 1487 0..n on the aggregate side and 1..n on the part side. This means 1488 that a particular SUPAECAPolicyRule MUST aggregate at least one 1489 SUPAPolicyClause, and that a given SUPAPolicyClause MAY be 1490 aggregated by zero or more SUPAECAPolicyRule objects. 1492 This cardinality MAY be refined to 3..n for SUPAECAPolicyRules, 1493 since a SUPAECAPolicyRule MUST have at least three separate clauses. 1494 However, since a SUPAPolicyStructure is the owner of this 1495 aggregation (which is inherited by SUPAECAPolicyRule), the 1496 cardinality is defined to be 1..n on the part side because other 1497 types of Policies have different needs. The 0..n cardinality 1498 means that a SUPAPolicyClause may be aggregated by zero or more 1499 SUPAECAPolicyRules. The zero is provided so that SUPAPolicyClauses 1500 can be stored in (for example) a repository before the 1501 SUPAECAPolicyRule is created; the "or more" recognizes the fact 1502 that multiple SUPAECAPolicyRules could aggregate the same 1503 SUPAPolicyClause. 1505 In Figure 7, suppose that SUPAHasPolicyClause#1, #2, and #3 1506 represent the aggregations for the event, condition, and action 1507 clauses, respectively. This means that each of these 1508 SUPAHasPolicyClause aggregations must explicitly identify the 1509 type of clause that it represents. 1511 In looking at Figure 7, there is no difference between any of the 1512 three aggregations, except for the type of clause that the 1513 aggregation represents (i.e., event, condition, or action clause). 1515 Therefore, three different aggregations, each with their own 1516 association class, is not needed. Instead, the GPIM defines a 1517 single aggregation (SUPAHasPolicyClause) that is realized using a 1518 (single) abstract association class (SUPAHasPolicyClauseDetail); 1519 this association class is then subclassed into three concrete 1520 subclasses, one each to represent the semantics for an event, 1521 condition, and action clause. 1523 The policy management system may use any number of different 1524 software mechanisms, such as introspection or reflection, to 1525 determine the nature of the aggregation (i.e., what object types 1526 are being aggregated) in order to select the appropriate subclass 1527 of SUPAHasPolicyClauseDetail. The three subclasses of 1528 SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail, 1529 SUPAHasPolicyConditionDetail, and SUPAHasPolicyActionDetail, 1530 respectively. While Event, Condition, and Action objects are 1531 typically used in ECA policy rules, the design in this document 1532 enables them to be used as policy components of other types of 1533 policies as well. This is shown in Figure 8. 1535 A A 1536 +-------------------+ +------------------+ 1537 | SUPAECAPolicyRule | | SUPAPolicyClause | 1538 +---------+---------+ +----------+-------+ 1539 / \ 1..n 0..n / \ 1540 A | 1541 \ / | 1542 | | 1543 | SUPAHasPolicyClause | 1544 +--------------+-----------------+ 1545 ^ 1546 | 1547 A | 1548 +--------------+------------+ 1549 | SUPAHasPolicyClauseDetail | 1550 +--------------+------------+ 1551 / \ 1552 I 1553 I 1554 +----------------+-----------------------+ 1555 I I I 1556 C I C I C I 1557 +--------+-----+ +-------+----------+ +---------+-----+ 1558 |Event subclass| |Condition subclass| |Action subclass| 1559 +--------------+ +------------------+ +---------------+ 1561 Figure 8. Instantiating a SUPAECAPolicyRule, part 2 1563 4.4.3. Creating SUPA Policy Clauses 1565 There are two different types of Policy Components. They are a 1566 SUPAPolicyClause and a SUPAPolicyComponentDecorator. The former 1567 is used to construct SUPAECAPolicyRules, while the latter is used 1568 to add behavior to a SUPAPolicyClause. This enables the structure 1569 and capabilities of the SUPAPolicyClause to be adjusted 1570 dynamically at runtime. 1572 However, since each SUPAECAPolicyRule can be made up of a variable 1573 number of SUPAPolicyComponents, the decorator pattern is used to 1574 "wrap" any concrete subclass of SUPAPolicyClause with zero or more 1575 concrete subclasses of the PolicyComponentDecorator object. This 1576 avoids problems of earlier models that resulted in a proliferation 1577 of classes and relationships. 1579 Figure 9 shows these two class subclasses. Note that the decorator 1580 pattern [11] is used to enable subclasses of the 1581 SUPAPolicyComponentDecorator class to add their attributes and/or 1582 behavior to a SUPAPolicyClause (as stated in section 4.3) without 1583 affecting the behavior of other objects from the same class. More 1584 specifically, concrete subclasses of the (abstract) 1585 SUPAPolicyComponentDecorator class can be used to decorate, or 1586 "wrap", any of the concrete subclasses of the (abstract) 1587 SUPAPolicyClause class. 1589 A 1590 +------------------------------+ 1..n 1591 | SUPAPolicyComponentStructure +----------------------+ 1592 +----------------+-------------+ | 1593 / \ | 1594 I SUPAHasPolicyComponentDecorators | 1595 I | 1596 +--------------+-----------+ | 1597 I I | 1598 A I A I | 1599 +---------+--------+ +--------------+---------------+ 0..1 | 1600 | | | |/ \ | 1601 | SUPAPolicyClause | | SUPAPolicyComponentDecorator + A -----+ 1602 | | | |\ / 1603 +------------------+ +------------------------------+ 1605 Figure 9. Subclasses of SUPAPolicyComponentStructure 1607 Instead of using inheritance to statically create new classes to 1608 represent new types of objects, the decorator pattern uses 1609 composition to dynamically combine attributes and behavior from 1610 existing objects into new objects. This is done by defining an 1611 interface in SUPAPolicyComponent that all of the subclasses of 1612 SUPAPolicyComponent conform to. Since the subclasses are of the 1613 same type as SUPAPolicyComponent, they all have the same interface. 1614 This allows each concrete SUPAPolicyComponentDecorator subclass to 1615 add its attributes and/or behavior to the concrete subclass of 1616 SUPAPolicyClause that it is decorating (or "wrapping"). 1618 This represents an important design optimization for data models. 1619 Note that a single SUPAECAPolicyRule can consist of any number of 1620 SUPAPolicyClauses, each of very different types. If inheritance 1621 was used, then a subclass AND an aggregation would be required for 1622 each separate clause that makes up the policy rule. 1624 Clearly, continuing to create subclasses is not practical. Worse, 1625 suppose composite objects are desired (e.g., a new object Foo is 1626 made up of existing objects Bar and Baz). If all that was needed 1627 was one attribute of Bar and two of Baz, the developer would still 1628 have to use the entire Bar and Baz classes. This is wasteful and 1629 inefficient. In contrast, the decorator pattern enables all, or 1630 just some, of the attributes and/or behavior of a class to "wrap" 1631 another class. This is used heavily in many production systems 1632 (e.g., the java.io package) because the result is only the 1633 behavior that is required, and no other objects are affected. 1635 The SUPAPolicyComponentDecorator class hierarchy is used to define 1636 objects that may be used to construct a SUPAPolicyClause. The 1637 decorator object can add behavior before, and/or after, it 1638 delegates to the object that it is decorating. The subclasses of 1639 SUPAPolicyComponentDecorator provide a very flexible and completely 1640 dynamic mechanism to: 1642 1) add or remove behavior to/from an object 1643 2) ensure that objects are constructed using the minimum amount 1644 of features and functionality required 1646 SUPAPolicyComponentDecorator defines four subclasses, as shown in 1647 Figure 10. 1648 A 1649 +------------------------------+ 1650 | SUPAPolicyComponentDecorator | 1651 +--------------+---------------+ 1652 / \ 1653 I 1654 I 1655 I 1656 +------------+-------------+----------------+ 1657 I I I I 1658 A I I C I I 1659 +--------+-------+ I +---------+------------+ I 1660 | SUPAPolicyTerm | I | SUPAPolicyCollection | I 1661 +----------------+ I +----------------------+ I 1662 (for defining I (for defining sets and/or I 1663 clauses in I groups of objects) I 1664 canonical form) I I 1665 I I 1666 C I A I 1667 +----------------+--------------+ +---------+--------+ 1668 | SUPAGenericDecoratedComponent | | SUPAECAComponent | 1669 +-------------------------------+ +------------------+ 1670 (for decorating concrete (for defining reusable 1671 subclasses of SUPAPolicyClause) event, condition, 1672 and action objects) 1674 Figure 10. Subclasses of SUPAPolicyComponentDecorator 1676 If a SUPAEncodedClause is being used, then there is no need to 1677 use any of the SUPAPolicyComponentDecorator subclasses, since 1678 the SUPAEncodedClause already completely defines the content of 1679 the SUPAPolicyClause. 1681 However, if a SUPAEncodedClause is NOT being used, then a 1682 SUPAPolicyClause will be constructed using one or more types of 1683 objects that are each subclasses of SUPAPolicyComponentDecorator. 1685 These four subclasses provide four different ways to construct a 1686 SUPAPolicyClause: 1688 1) SUPAPolicyTerm: as a {variable, operator, value} clause 1689 2) SUPAEncodedClause: as an encoded object (e.g., to pass YANG 1690 or CLI code) 1691 3) SUPAPolicyCollection: as a collection of objects that 1692 requires further processing in order to be made into a 1693 SUPAPolicyClause 1694 4) SUPAECAComponent: subclasses define reusable Event, 1695 Condition, or Action objects 1697 These four different types of objects can be intermixed. For 1698 example, the first and last types can be combined as follows: 1700 Variable == Event.baz (A) 1701 Condition BETWEEN VALUE1 and VALUE2 (B) 1702 (Event.severity == 'Critical' AND 1703 (SLA.violation == TRUE OR User.class == 'Gold')) (C) 1705 In the above rules, (A) uses Event.baz to refer to an attribute 1706 of the Event class; (B) defines two different instances of a Value 1707 class, denoted as Value1 and Value2; (C) uses the nomenclature 1708 foo.bar, where foo is the name of a class, and bar is the name of 1709 an attribute of that class. 1711 4.4.4. Creating SUPAPolicyClauses 1713 The GPIM defines a single subclass of SUPAPolicyClause, called 1714 SUPAEncodedClause. This clause is generic in nature, and MAY be 1715 used with any type of policy (ECA or otherwise). The EPRIM 1716 defines an ECA-specific subclass of the GPIM, called a 1717 SUPABooleanClause, which is intended to be used with just 1718 ECA policy rules; however, other uses are also possible. 1720 Together, the GPIM and EPRIM provide several alternatives to 1721 implement a SUPAPolicyClause, enabling the developer to 1722 optimize the solution for different constraints: 1724 1) The SUPAPolicyClause can be encoded using one or more 1725 SUPAEncodedClauses; a SUPAEncodedClause encodes the 1726 entire content of its respective event, condition, or 1727 action clause. 1728 2) The SUPAPolicyClause can be defined using one or more 1729 SUPABooleanClauses; each of the three clauses can be 1730 defined as either a single SUPABooleanClause, or a 1731 combination of SUPABooleanClauses that are logically 1732 ANDed, ORed, and/or NOTed. 1733 3) The above two mechanisms can be combined (e.g., the first 1734 used to define the event clause, and the second used to 1735 define the condition and action clauses). 1737 Figure 11 shows the subclasses of SUPAPolicyClause. 1739 A 1740 +------------------+ 1741 | SUPAPolicyClause | 1742 +--------+---------+ 1743 / \ 1744 I 1745 I 1746 I 1747 +---------------+-------------+ 1748 I I 1749 A I C I 1750 +--------+----------+ +----------+--------+ 1751 | SUPABooleanClause | | SUPAEncodedClause | 1752 +-------------------+ +-------------------+ 1754 Figure 11. Subclasses of SUPAPolicyClause 1756 SUPABooleanClause is defined in the EPRIM, and is used to 1757 construct Boolean clauses that collectively make up a 1758 SUPAPolicyClause. It is abstract, so that the composite pattern 1759 can be applied to it, which enables hierarchies of Boolean 1760 clauses to be created. SUPAEncodedClause (see section 6.7) is 1761 used to encode the content of a SUPAPolicyClause as an attribute 1762 (instead of reusable objects). 1764 4.4.5. SUPAPolicySources 1766 A SUPAPolicySource is a set of managed entities that authored, 1767 or are otherwise responsible for, this SUPAPolicy. Note that a 1768 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 1769 primary use is for auditability, authorization policies, and 1770 other applications of deontic and/or alethic logic. 1772 SUPAPolicyStructure defines four relationships. Two of these 1773 (SUPAHasPolicySource and SUPAHasPolicyTarget), which are both 1774 aggregations, relate a SUPAPolicyStructure to a SUPAPolicySource 1775 and a SUPAPolicyTarget, respectively. Since SUPAECAPolicyRule is 1776 a subclass of SUPAPolicyStructure, it (and its subclasses) inherit 1777 both of these aggregations. This enables SUPAPolicySources and/or 1778 SUPAPolicyTargets to be attached to SUPAECAPolicyRules (but NOT to 1779 components of a SUPAPolicy). 1781 Figure 12 shows how SUPAPolicySources and SUPAPolicyTargets are 1782 attached to a SUPAPolicy. Note that both of these aggregations 1783 are defined as optional, since their multiplicity is 0..n - 0..n. 1784 In addition, both of these aggregations are realized as 1785 association classes, in order to be able to control which 1786 SUPAPolicySources and SUPAPolicyTargets are attached to a given 1787 SUPAECAPolicyRule. 1789 A 1790 +------------------+ 1791 | SUPAPolicyObject | 1792 +--------+---------+ 1793 / \ 1794 I 1795 I 1796 I 1797 +--------------+-----+---------------------+ 1798 I I I 1799 A I C I C I 1800 +-----------+---------+ +-------+--------+ +--------+-------+ 1801 | SUPAPolicyStructure | |SUPAPolicySource| |SUPAPolicyTarget| 1802 +------+-------+------+ +----------+-----+ +----------+-----+ 1803 0..n / \ / \ 0..n 0..n / \ 0..n / \ 1804 A A | | 1805 \ / \ / | | 1806 | | | | 1807 | | | | 1808 | +--------------------+ | 1809 | SUPAHasPolicySource | 1810 | | 1811 +-------------------------------------------------+ 1812 SUPAHasPolicyTarget 1814 Figure 12. ECAPolicyRules, SUPAPolicySources, and PolicyTargets 1816 A SUPAPolicySource MAY be mapped to a role (e.g., using the 1817 role-object pattern [11]); this indirection makes the system less 1818 fragile, as entities can be transparently added or removed from 1819 the role definition without adversely affecting the definition of 1820 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 1821 SUPAPolicyMetadata. 1823 4.4.6. SUPAPolicyTargets 1825 A SUPAPolicyTarget defines the set of managed entities that a 1826 SUPAPolicy is applied to. This is useful for debugging, as well as 1827 when the nature of the application requires the set of managed 1828 entities affected by a Policy to be explicitly identified. This is 1829 determined by two conditions: 1831 1) The set of managed entities that are to be affected by the 1832 SUPAPolicy must all agree to play the role of a 1833 SUPAPolicyTarget. For example, a managed entity may not be 1834 in a state that enables SUPAPolicies to be applied to it; 1835 hence, in this case, it MUST NOT assume the role of a 1836 SUPAPolicyTarget 1837 2) A SUPAPolicyTarget must be able to: 1838 a) process (either directly or with the aid of a proxy) 1839 SUPAPolicies, or 1840 b) receive the results of a processed SUPAPolicy and 1841 apply those results to itself. 1843 Figure 12 showed how SUPAPolicyTargets are attached to 1844 SUPAECAPolicyRules. 1846 A SUPAPolicyTarget MAY be mapped to a role (e.g., using the 1847 role-object pattern [11]); this indirection makes the system less 1848 fragile, as entities can be transparently added or removed from 1849 the role definition without adversely affecting the definition of 1850 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 1851 SUPAPolicyMetadata. 1853 4.4.7. Policy Metadata 1855 Metadata is, literally, data about data. As such, it can be 1856 descriptive or prescriptive in nature. 1858 4.4.7.1. Motivation 1860 There is a tendency in class design to make certain attributes, 1861 such as description, status, validFor, and so forth, bound to a 1862 specific class (e.g., [6]). This is bad practice in an information 1863 model. For example, different classes in different parts of the 1864 class hierarchy could require the use of any of these attributes; 1865 if one class is not a subclass of the other, then they must each 1866 define the same attribute as part of their class structure. This 1867 makes it difficult to find all instances of the attribute and 1868 ensure that they are synchronized. Furthermore, context can 1869 dynamically change the status of an object, so an easy way to 1870 update the status of one object instance without affecting other 1871 instances of the same object is required. 1873 Many models, such as [4] and [6], take a simplistic approach of 1874 defining a common attribute high in the hierarchy, and making it 1875 optional. This violates classification theory, and defeats the 1876 purpose of an information model, which is to specify the 1877 differences in characteristics and behavior between classes (as 1878 well as define how different classes are related to each other). 1879 Note that this also violates a number of well-known software 1880 architecture principles, including: 1882 o the Liskov Substitution Principle [13] 1883 (if A is a subclass of B, then objects instantiated from 1884 class B may be replaced with objects instantiated from 1885 class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS) 1886 o the Single Responsibility Principle [14] 1887 (every class should have responsibility over one, and only 1888 one, part of the functionality provided by the program) 1889 o the Open/Closed Principle (software should be open for 1890 extension, but closed for modification) [17] 1891 o the Interface-Segreation Principle (clients should not be 1892 forced to depend on methods that they do not use) [14] 1893 o the Dependency Inversion Principle (high-level modules should 1894 not depend on low-level modules; both should depend on 1895 abstractions) [14] 1897 Most models use inheritance, not composition. The former is 1898 simpler, but has some well-known problems. One is called "weak 1899 encapsulaton", meaning that a subclass can use attributes and 1900 methods of a superclass, but if the superclass changes, the 1901 subclass may break. Another is that each time a new object is 1902 required, a new subclass must be created. These problems are 1903 present in [RFC3460], [4], and [6]. 1905 Composition is an alternative that provides code that is easier to 1906 use. This means that composition can provide data models that are 1907 more resistant to change and easier to use. By using composition, 1908 we can select just the metadata objects that are needed, instead 1909 of having to rely on statically defined objects. We can even 1910 create new objects from a set of existing objects through 1911 composition. Finally, we can use the decorator pattern to select 1912 just the attributes and behaviors that are required for a given 1913 instance. 1915 In [2] and [5], a separate metadata class hierarchy is defined to 1916 address this problem. This document follows this approach. 1918 4.4.7.2. Design Approach 1920 The goal of the GPIM is to enable metadata to be attached to any 1921 subclass of SUPAPolicyObject that requires it. Since this is a 1922 system intended for policy-based management, it therefore makes 1923 sense to be able to control which metadata is attached to which 1924 policies dynamically (i.e., at runtime). 1926 One solution is to use the Policy Pattern [1], [2], [6], [12]. 1927 This pattern was built to work with management systems whose 1928 actions were dependent upon context. The Policy Pattern works as 1929 follows: 1931 o Context is derived from all applicable system inputs (e.g., 1932 OAMP data from network elements, business goals, time of 1933 day, geo-location, etc.). 1934 o Context is then used to select a working set of Policies. 1935 o Policies are then used to define behavior at various 1936 control points in the system. 1937 o One simple type of control point is an association class. 1938 Since the association class represents the semantics of how 1939 two classes are related to each other, then 1940 o ECAPolicyRule actions can be used to change the attribute 1941 values, methods, and relationships of the association 1942 class 1943 o This has the affect of changing how the two classes are 1944 related to each other 1945 o Finally, as context changes, the working set of policies 1946 change, enabling the behavior to be adjusted to follow 1947 changes in context (according to appropriate business goals 1948 and other factors, of course) in a closed loop manner. 1950 Conceptually, this is accomplished as shown in Figure 13 below. 1952 Defines 1953 +----------+ Behavior +------------+ 1954 | Policies +----------------+ | SUPAPolicy | 1955 +----+-----+ 1..n | +------+-----+ 1956 0..n / \ | / \ 0..n 1957 | | A 1958 | | \ / 1959 | 1..n \ / | 1960 | +-----------+--------------+ | 1961 | | SUPAPolicyMetadataDetail | | 1962 | +-----------+--------------+ | 1963 | | | 1964 | Selects | | 1965 | Policies | | 1966 | | | 1967 | +-------------------->+ 1968 | Applies | 1969 / \ Behavior | 1970 A | 1971 0..n \ / \ / 0..n 1972 +----+-----+ +--------+---------+ 1973 | Context | |SUPAPolicyMetadata| 1974 +----------+ +------------------+ 1976 Figure 13. Context-Aware Policy Rules 1978 4.4.7.2.1. Policies and Actors 1980 The Policy Continuum ([1] [5] [10] [12]) was defined to associate 1981 different actors with different policies at different levels of 1982 business and/or technical specificity. Context-aware policy rules, 1983 and the Policy Pattern, were defined to realize this association. 1985 Four important functions related to the lifecycle of policies are 1986 design, implementation, deployment, and execution. There are many 1987 different possible definitions of these functions (even for policy 1988 lifecycle management); however, for the purposes of this document, 1989 they are defined as follows: 1991 o Design: The process of defining a software architecture 1992 to satisfy user requirements. 1993 o Development: the process of documenting, programming, 1994 testing, and maintaining code and applications 1995 as part of a software product 1996 o Deployment: the process that assembles and transfers 1997 completed software artifacts to a state that 1998 enables their execution 1999 o Execution: the process of installing, activating, running, 2000 and subsequently deactivating executable 2001 software products 2003 The design process is responsible for producing a software 2004 architecture. This emphasizes the design, as opposed to the 2005 programming, of software systems. In contrast to design, 2006 development emphasizes constructing software artifacts via coding 2007 and documentation. 2009 Deployment may be described as the process of releasing software. 2010 It includes all of the operations required to assemble a completed 2011 software product. It typically also includes the process of 2012 preparing a software product for execution (e.g., assembling a set 2013 of software products into a larger product, determining if the 2014 consumer site has appropriate resources to install and execute the 2015 software product, and collecting information on the feasibility of 2016 using the software product). This contrasts with the execution 2017 process, which is the set of processes that follow deployment. 2019 In summary, exemplar states in the policy lifecycle process 2020 include: 2022 o Design: determining how the policy-based management 2023 system will operate 2024 o Development: documenting, programming, testing, and 2025 maintaining policies and policy components 2026 o Deployment: assembling the components of a policy-based 2027 management system 2028 o Execution: installing, enabling, running, disabling, 2029 and uninstalling policies and policy components 2031 4.4.7.2.2. Deployment vs. Execution of Policies 2033 One of the primary reasons for separating the deployment and 2034 execution processes is to differentiate between environments that 2035 are not ready to execute policies (i.e., deployment) and 2036 environments that are ready to execute policies (i.e., execution). 2037 This is an important consideration, since policies that are 2038 related to the same set of tasks may be deployed in many different 2039 places (e.g., in a policy system vs. in a network device). In 2040 addition, each managed entity in the set of SUPAPolicyTargets may 2041 or may not be in a state that allows SUPAPolicies to be applied to 2042 it (see section 4.4.6.). 2044 Hence, this design includes dedicated class attributes for 2045 getting and setting the deployment and execution status, as well 2046 as enabling and disabling, SUPAPolicies (see section 5.3.1.). 2048 4.4.7.2.3. Using SUPAMetadata for Policy Deployment and Execution 2050 One way of encoding deployment and execution status for policies 2051 and policy components is to attach Metadata objects to affected 2052 SUPAPolicyStructure and SUPAPolicyComponentStructure objects. 2053 This provides an extensible and efficient means to describe 2054 and/or prescribe deployment and/or execution status of a policy 2055 or a policy component. It is extensible, since classes and 2056 relationships can be used, as opposed to a set of attributes. It 2057 is efficient, because the decorator pattern (see section 5.7) is 2058 used (this enables attributes and/or methods of objects, or the 2059 entire object, to be used to add characteristics and/or behavior 2060 to a given object. 2062 SUPAPolicyMetadata objects (see sections 5.16 - 5.20) may be 2063 attached to the SUPAECAPolicyRule and/or any of its components 2064 to define additional semantics of the SUPAECAPolicyRule. For 2065 example, SUPAAccessMetadataDef (see section 5.19) and/or 2066 SUPAVersionMetadataDef (see section 5.20) may be attached to 2067 define the access privileges and version information, 2068 respectively, of a policy rule and/or its components. 2070 The SUPAPolicyStructure contains two attributes, 2071 supaPolDeployStatus and supaPolExecStatus (see sections 5.3.1.3. 2072 and 5.3.1.4., respectively) that SUPAPolicyMetadata objects can 2073 use to get and set the deployment and execution status of a 2074 SUPAPolicy. This allows metadata to be used to alter the 2075 deployment and/or execution state of a policy (or a set of 2076 policy components) without having to affect other parts of the 2077 policy-based management system. The supaPolDeployStatus attribute 2078 indicates that this SUPAPolicy can or cannot be deployed. If it 2079 cannot be deployed. Similarly, the supaPolExecStatus attribute 2080 is used to indicate if a particular SUPAPolicy has executed, is 2081 currently executing, or is ready to execute, and whether or not 2082 the execution of that SUPAPolicy had any failures. 2084 The reverse is also true (and hence, forms a closed-loop system 2085 controlled by metadata). For example, if the set of deployed 2086 SUPAPolicies are SUPAECAPolicyRules, then when the actions of 2087 these SUPAECAPolicyRules are executed, the overall context has 2088 changed (see section 4.4.7.2). The context manager could then 2089 change attribute values (directly or indirectly) in the 2090 SUPAPolicyMetadataDetail association class. This class represents 2091 the behavior of the SUPAHasPolicyMetadata aggregation, which is 2092 used to define which SUPAPolicyMetadata can be attached to which 2093 SUPAPolicy objet in this particular context. For example, the 2094 access privileges of a policy and/or policy component could be 2095 changed dynamically, according to changes in context. 2097 By using the decorator pattern on SUPAPolicyMetadata, any number 2098 of SUPAPolicyMetadata objects (or their attributes, etc.) can be 2099 wrapped around a concrete subclass of SUPAPolicyMetadata. This is 2100 shown in Figure 14 below. 2102 4.4.7.3. Structure of SUPAPolicyMetadata 2104 SUPAPolicyMetadata also uses the decorator pattern to provide an 2105 extensible framework for defining metadata to attach to SUPAPolicy 2106 subclasses. Its two principal subclasses are 2107 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. The 2108 former is used to define concrete subclasses of SUPAPolicyMetadata 2109 that are attached at runtime to SUPAPolicy subclasses, while the 2110 latter is used to define concrete objects that represent reusable 2111 attributes, methods, and relationships that can be added to 2112 subclasses of SUPAPolicyConcreteMetadata. 2114 For example, concepts like identification, access control, and 2115 version information are too complex to represent as a single 2116 attribute, or even a couple of attributes - they require the 2117 generic power of objects to represent their characteristics and 2118 behavior. Furthermore, defining concrete classes to represent 2119 these concepts in the policy hierarchy is fragile, because: 2121 1. not all objects that use these concepts need all of the 2122 information represented by them (e.g., two subclasses of an 2123 Identification Object may be Passport and Certificate, but 2124 these two objects are rarely used together, and even those 2125 contexts that use one of these classes may not need all of 2126 the data in that class) 2127 2. defining a class means defining its attributes, methods, and 2128 relationships at a particular place in the hierarchy; this 2129 means that defining a relationship between a class A and 2130 another class B SHOULD only be done if all of the subclasses 2131 of B can use the attributes, methods, and relationships of A 2132 (e.g., in the above example, defining a relationship between 2133 an Identification Object and a superclass of a router class 2134 is not appropriate, since routers do not use Passports) 2136 A 2137 +------------------+ 2138 | SUPAPolicyObject | 2139 +--------+---------+ 2140 / \ 0..n 2141 A 2142 \ / 2143 | A 2144 | 0..n +--------------------+ 2145 | SUPAHasPolicyMetadata \| | 2146 +-------------+-----------------+ SUPAPolicyMetadata | 2147 ^ /| | 2148 | +------+------+------+ 2149 C | / \ | 1..n 2150 +-------------+---------------+ I | 2151 1..n | | I | 2152 +----------+ SUPAHasPolicyMetadataDetail | I | 2153 | | | I | 2154 | +-----------------------------+ I | 2155 | I | 2156 | (gets/sets values of attributes and/or I | 2157 | methods of the SUPAHasPolicyMetadataDetail I | 2158 | class; this affects which SUPAPolicyMetadata I | 2159 | objects can be attached to which policies I | 2160 | and policy components) I | 2161 | I | 2162 | C I | 2163 | +----------------------------+ I | 2164 | | | I | 2165 +----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+ | 2166 | | I | 2167 +----------------------------+ I | 2168 I | 2169 A I | 2170 +-----------------------------+ I | 2171 | | I | 2172 | SUPAPolicyMetadataDecorator +IIIIIIIII+ | 2173 | | | 2174 +-------+--------------+------+ | 2175 / \ / \ 0..1 | 2176 I A | 2177 I \ / | 2178 I | | 2179 subclasses for adding | | 2180 behavior to policies +-----------------------+ 2181 and policy components SUPAHasMetadataDecorator 2183 Figure 14. SUPAPolicyMetadata Subclasses and Relationships 2185 Since a class encapsulates attributes, methods, and behavior, 2186 defining the Identification Object in the above example as a type 2187 of SUPAPolicyMetadata object enables the decorator pattern to be 2188 used to attach all or part of that object to other objects that 2189 need it. 2191 Figure 15 shows a portion of the SUPAPolicyMetadata hierarchy. 2193 A 2194 +--------------------+ 2195 | | SUPAHasMetadataDecorator 2196 | SUPAPolicyMetadata +-------------------+ 2197 | | 1..n | 2198 +---------+----------+ | 2199 I | 2200 I | 2201 I | 2202 +-------------+-----------------+ | 2203 | | | 2204 C | | / \ 2205 +---------+------------------+ | A 2206 | SUPAPolicyConcreteMetadata | A | 0..1 \ / 2207 +----------------------------+ +--------+------------+-------+ 2208 | SUPAPolicyMetadataDecorator | 2209 +------------+----------------+ 2210 I 2211 +------------------------------+--------+ 2212 I I 2213 I I 2214 C I C I 2215 +---------------+-------------+ +---------------------+--------+ 2216 | SUPAPolicyAccessMetadataDef | | SUPAPolicyVersionMetadataDef | 2217 +-----------------------------+ +------------------------------+ 2219 Figure 15. SUPAPolicyMetadata Subclasses and Relationships 2221 Figure 15 shows a relevant portion of the SUPAPolicyMetadata 2222 hierarchy. SUPAPolicyConcreteMetadata is a concrete class that 2223 subclasses of the SUPAPolicyMetadataDecorator class can wrap. 2224 Two such subclasses, SUPAPolicyAccessMetadataDef and 2225 SUPAPolicyVersionMetadataDef, are shown in Figure 15. This 2226 enables access control and version information to be added 2227 statically (at design time) or dynamically (at runtime) to 2228 SUPAPolicyConcreteMetadata; this enables metadata-driven systems 2229 to adjust the behavior of the management system to changes in 2230 context, business rules, services given to end-users, and other 2231 similar factors. This is discussed more in sections 5.18 - 5.20. 2233 4.5. Advanced Features 2235 This section will be completed in the next revision of this 2236 document. 2238 4.5.1. Policy Grouping 2240 This section will be completed in the next revision of this 2241 document. 2243 4.5.2. Policy Rule Nesting 2245 This section will be completed in the next revision of this 2246 document. 2248 5. GPIM Model 2249 This section defines the classes, attributes, and relationships of 2250 the GPIM. 2252 5.1. Overview 2253 The overall class hierarchy is shown in Figure 16; section numbers 2254 are appended after each class. 2256 (Class of another model that SUPA is integrating into) 2257 | 2258 +---SUPAPolicyObject (5.2) 2259 | | 2260 | +---SUPAPolicyStructure (5.3) 2261 | | 2262 | +---SUPAPolicyComponentStructure (5.4) 2263 | | | 2264 | | +---SUPAPolicyClause (5.5) 2265 | | | | 2266 | | | +---SUPAEncodedClause (5.6) 2267 | | | 2268 | | +---SUPAPolicyComponentDecorator (5.7) 2269 | | | 2270 | | +---SUPAPolicyTerm (5.8) 2271 | | | | 2272 | | | +---SUPAPolicyVariable (5.9) 2273 | | | | 2274 | | | +---SUPAPolicyOperator (5.10) 2275 | | | | 2276 | | | +---SUPAPolicyValue (5.11) 2277 | | | 2278 | | +---SUPAGenericDecoratedComponent (5.12) 2279 | | | 2280 | | +---SUPAPolicyCollection (5.13) 2281 | | 2282 | +---SUPAPolicySource (5.14) 2283 | | 2284 | +---SUPAPolicyTarget (5.15) 2285 | 2286 +---SUPAPolicyMetadata (5.16) 2287 | 2288 +---SUPAPolicyConcreteMetadata (5.17) 2289 | 2290 +---SUPAPolicyMetadataDecorator (5.18) 2291 | 2292 +---SUPAPolicyAccessMetadataDef (5.19) 2293 | 2294 +---SUPAPolicyVersionMetadataDef (5.20) 2296 Figure 16: Main Classes of the GPIM 2298 SUPAPolicy is the root of the SUPA class hierarchy. For 2299 implementations, it is assumed that SUPAPolicy is subclassed from 2300 a class from another model. 2302 Classes, attributes, and relationships that are marked as 2303 "mandatory" MUST be part of a conformant implementation (i.e., a 2304 schema MUST contain these entities). This does not mean that these 2305 entities must be instantiated; rather it means that they must be 2306 able to be instantiated. Classes, attributes, and relationships 2307 that are marked as "optional" MAY be part of a conformant 2308 implementation. 2310 Unless otherwise stated, all classes (and attributes) defined in 2311 this section were abstracted from DEN-ng [2], and a version of 2312 them are in the process of being added to [5]. However, the work 2313 in [5] has been put on hold, and the names of many of the classes, 2314 attributes, and relationships are slightly different. 2316 5.2. The Abstract Class "SUPAPolicyObject" 2318 This is a mandatory abstract class. Figure 17 shows the 2319 SUPAPolicyObject class, and its four subclasses. 2321 A 0..n 0..n A 2322 +----------------+/ \ \+------------------+ 2323 |SUPAPolicyObject+ A ------------------------+SUPAPolicyMetadata| 2324 +--------+-------+\ / SUPAHasPolicyMetadata /+------------------+ 2325 / \ 2326 I 2327 I 2328 +-----------------+----------------+-----------+ 2329 I I I I 2330 A I I I I 2331 +--------+------------+ I I I 2332 | SUPAPolicyStructure | I I I 2333 +---------------------+ I I I 2334 A I I I 2335 +-----------------+------------+ I I 2336 | SUPAPolicyComponentStructure | I I 2337 +------------------------------+ I I 2338 C I I 2339 +---------+--------+ I 2340 | SUPAPolicyTarget | I 2341 +------------------+ I 2342 C I 2343 +----------+-------+ 2344 | SUPAPolicySource | 2345 +------------------+ 2347 Figure 17. SUPAPolicyObject and Its Subclasses 2349 This class is the root of the SUPA class hierarchy. It defines the 2350 common attributes and relationships that all SUPA subclasses 2351 inherit. 2353 A SUPAPolicyObject MAY be qualified by a set of zero or more 2354 SUPAPolicyMetadata objects. This is provided by the 2355 SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This 2356 enables the semantics of the SUPAPolicyObject to be more 2357 completely specified. 2359 5.2.1. SUPAPolicyObject Attributes 2361 This section defines the attributes of the SUPAPolicyObject class. 2362 These attributes are inherited by all subclasses of the GPIM 2363 except for the SUPAPolicyMetadata class, which is a sibling class. 2365 5.2.1.1. Object Identifiers 2367 This document defines two class attributes in SUPAPolicyObject, 2368 called supaPolObjIDContent and supaPolObjIDEncoding, that together 2369 define a unique object ID. This enables all class instances to be 2370 uniquely identified. 2372 One of the goals of SUPA is to be able to generate different data 2373 models that support different types of protocols and repositories. 2374 This means that the notion of an object ID must be generic. It is 2375 inappropriate to use data modeling concepts, such as keys, Globally 2376 Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs), 2377 Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names 2378 (FQPNs), Uniform Resource Identifiers (URIs), and other similar 2379 mechanisms, to define the structure of an information model. 2380 Therefore, a synthetic object ID is defined using these two class 2381 attributes. This can be used to facilitate mapping to different data 2382 model object schemes. 2384 The two attributes work together, with the supaPolObjIDContent 2385 attribute defining the content of the object ID and the 2386 supaPolObjIDEncoding attribute defining how to interpret the 2387 content. These two attributes form a tuple, and together enable 2388 a machine to understand the syntax and value of an object 2389 identifier for the object instance of this class. 2391 Similarly, all SUPA classes are attributes are both uniquely 2392 named as well as prepended with the prefixes "SUPA" and "supa", 2393 respectively, to facilitate model integration. 2395 5.2.1.2. The Attribute "supaPolObjIDContent" 2397 This is a mandatory string attribute that represents part of the 2398 object identifier of an instance of this class. It defines the 2399 content of the object identifier. It works with another class 2400 attribute, called supaPolObjIDEncoding, which defines how to 2401 interpret this attribute. These two attributes form a tuple, 2402 and together enable a machine to understand the syntax and value 2403 of an object identifier for the object instance of this class. 2404 This is based on the DEN-ng class design [2]. 2406 5.2.1.3. The Attribute "supaPolObjIDEncoding" 2408 This is a mandatory non-zero enumerated integer attribute that 2409 represents part of the object identifier of an instance of this 2410 class. It defines the format of the object identifier. It works 2411 with another class attribute, called supaPolObjIDContent, which 2412 defines the content of the object ID. These two attributes form 2413 a tuple, and together enable a machine to understand the syntax 2414 and value of an object identifier for the object instance of 2415 this class. The supaPolObjIDEncoding attribute is mapped to the 2416 following values: 2418 0: undefined 2419 1: GUID 2420 2: UUID 2421 3: primary key 2422 4: foreign key 2423 5: URI 2424 6: FQDN 2425 7: FQPN 2427 The value 0 may be used to initialize the system, or to signal 2428 that there is a problem with this particular SUPAPolicyObject. 2430 5.2.1.4. The Attribute "supaPolicyDescription" 2432 This is an optional string attribute that defines a free-form 2433 textual description of this object. 2435 5.2.1.5. The Attribute "supaPolicyName" 2437 This is an optional string attribute that defines the name of this 2438 Policy. This enables any existing generic naming attribute to be 2439 used for generic naming, while allowing this attribute to be used 2440 to name Policy entities in a common manner. Note that this is NOT 2441 the same as the commonName attribute of the Policy class defined 2442 in [RFC3060], as that attribute is intended to be used with just 2443 X.500 cn attributes. 2445 5.2.2. SUPAPolicyObject Relationships 2447 The SUPAPolicyObject class currently defines a single relationship, 2448 as defined in the subsections below. 2450 5.2.2.1. The Aggregation "SUPAHasPolicyMetadata" 2452 This is a mandatory aggregation that defines the set of 2453 SUPAPolicyMetadata that are aggregated by this particular 2454 SUPAPolicyObject. This aggregation is defined in section 2455 5.16.2. 2457 5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail" 2459 This is a mandatory concrete association class that defines the 2460 semantics of the SUPAPolicyMetadata aggregation. This enables the 2461 attributes and relationships of the SUPAPolicyMetadataDetail class 2462 to be used to constrain which SUPAPolicyMetadata objects can be 2463 aggregated by this particular SUPAPolicyObject instance. This 2464 association class is defined in Section 5.16.2.2. 2466 5.3. The Abstract Class "SUPAPolicyStructure" 2468 This is a mandatory abstract class that is used to represent the 2469 structure of a SUPAPolicy. This class (and all of its subclasses) 2470 is a type of PolicyContainer. SUPAPolicyStructure was abstracted 2471 from DEN-ng [2], and a version of this class is in the process of 2472 being added to [5]. However, the version in [5] differs 2473 significantly. First, the class and relationship definitions ared 2474 different. Second, [5] uses the composite pattern. Neither of 2475 these are implemented in this document because of optimizations 2476 done to the SUPA class hierarchy that are NOT present in [5]. 2478 For this release, the only official type of policy that is 2479 supported is the event-condition-action (ECA) type of policy rule. 2480 However, the structure of the SUPA hierarchy is defined to 2481 facilitate adding new types of rules later. 2483 A SUPAPolicy may take the form of an individual policy or a set 2484 of policies. This requirement is supported by applying the 2485 composite pattern to subclasses of the SUPAPolicyStructure class, 2486 as shown in Figure 5. In this document, this is done for the 2487 SUPAECAPolicyRule subclass, and results in two subclasses: 2488 SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and 2489 SUPAECAPolicyRuleComposite (for defining hierarchies of policies). 2491 Note that there is no need for a "match strategy attribute" that 2492 some models [RFC3460], [4], [6] have; this is because the 2493 SUPAPolicyStructure class is used just for containment. Hence, the 2494 containers themselves serve as the scoping component for nested 2495 policies. 2497 5.3.1. SUPAPolicyStructure Attributes 2499 The following subsections define the attributes of the 2500 SUPAPolicyStructure class. 2502 The SUPAPolicyStructure class has a number of attributes that have 2503 no counterpart in the SUPAPolicyComponentStructure class. This is 2504 because these attributes are only appropriate at the level of a 2505 policy rule, not at the level of a policy component. 2507 Care must be taken in adding attributes to this class, 2508 because the behavior of future subclasses of this class (e.g., 2509 declarative and functional policies) is very different than the 2510 behavior of SUPAECAPolicyRules. 2512 5.3.1.1. The Attribute "supaPolAdminStatus" 2514 This is an optional attribute, which is an enumerated non-negative 2515 integer. It defines the current administrative status of this 2516 SUPAPolicyClause. 2518 This attribute can be used to place this particular 2519 SUPAPolicyStructure object instance into a specific administrative 2520 state, such as enabled, disabled, or in test. Values include: 2522 0: Unknown (an error state) 2523 1: Enabled 2524 2: Disabled 2525 3: In Test (i.e., no operational traffic can be passed) 2527 Value 0 denotes an error that prevents this SUPAPolicyStructure 2528 from being used. Values 1 and 2 mean that this SUPAPolicyStructure 2529 is administratively enabled or disabled, respectively. A value of 2530 3 means that this SUPAPolicyStructure is in a special test mode 2531 and SHOULD NOT be used as part of an OAM&P policy. 2533 5.3.1.2. The Attribute "supaPolContinuumLevel" 2535 This is an optional non-negative integer attribute. It defines 2536 the level of abstraction, or policy continuum level [10], of this 2537 particular SUPAPolicy. The value assignment of this class is 2538 dependent on the application; however, it is recommended that 2539 for consistency with other SUPA attributes, the value of 0 is 2540 reserved for initialization and/or error conditions. 2542 By convention, lower values represent more abstract levels of the 2543 policy continuum. For example, a value of 1 could represent 2544 business policy, a value of 2 could represent application-specific 2545 policies, and a value of 3 could represent low=level policies for 2546 network administrators. 2548 5.3.1.3. The Attribute "supaPolDeployStatus" 2550 This is an optional enumerated, non-negative integer attribute. The 2551 purpose of this attribute is to indicate that this SUPAPolicy can 2552 or cannot be deployed by the policy management system. This 2553 attribute enables the policy manager to know which SUPAPolicies to 2554 retrieve, and may be useful for the policy execution system for 2555 planning the staging of SUPAPolicies. Values include: 2557 0: undefined 2558 1: deployed and enabled 2559 2: deployed and in test 2560 3: deployed but not enabled 2561 4: ready to be deployed 2562 5: cannot be deployed 2564 If the value of this attribute is 0 or 5, then the policy 2565 management system SHOULD ignore this SUPAPolicy. Otherwise, the 2566 policy management MAY use this SUPAPolicy. 2568 5.3.1.4. The Attribute "supaPolExecStatus" 2570 This is an optional attribute, which is an enumerated, 2571 non-negative integer. It defines the current execution status 2572 of this SUPAPolicy. Values include: 2574 0: undefined 2575 1: executed and SUCCEEDED (operational mode) 2576 2: executed and FAILED (operational mode) 2577 3: currently executing (operational mode) 2578 4: ready to execute (operational mode) 2579 5: executed and SUCCEEDED (test mode) 2580 6: executed and FAILED (test mode) 2581 7: currently executing (test mode) 2582 8: ready to execute (test mode) 2584 5.3.1.5. The Attribute "supaPolExecFailStrategy" 2586 This is an optional non-negative, enumerated integer that defines 2587 what actions, if any, should be taken by this 2588 SUPAPolicyStructure object if it fails to execute correctly. 2590 Note that some systems may not be able to support all options 2591 specified in this enumeration. If rollback is supported by the 2592 system, then option 2 may be skipped. Options 3 and 4 can be used 2593 by systems that do and do not support rollback. Values include: 2595 0: undefined 2596 1: attempt rollback of all actions taken and stop execution 2597 2: attempt rollback of only the action that failed and stop 2598 execution 2599 3: stop execution but do not rollback any actions 2600 4: ignore failure and continue execution 2602 A value of 0 can be used as an error condition. A value of 1 means 2603 that ALL execution is stopped, rollback of all actions (whether 2604 successful or not) is attempted, and that SUPAPolicies that 2605 otherwise would have been executed are ignored. A value of 2 means 2606 that execution is stopped, and rollback is attempted for ONLY the 2607 SUPAPolicy that failed to execute correctly. 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 "supaPolExecFailTakeActionEncoding" 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: undefined 2744 1: String 2745 2: GUID 2746 3: UUID 2747 4: URI 2748 5: FQDN 2749 6: FQPN 2751 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" 2753 This is an optional array of string attributes that identifies the 2754 set of policy actions to take if the SUPAPolicyStructure object 2755 that owns this association failed to execute properly. The 2756 interpretation of this string attribute is defined by the 2757 supaPolExecFailTakeActionEncoding class attribute. The association 2758 defines the SUPAPolicyStructure that contains the set of policy 2759 actions to execute, and this attribute defines which of these 2760 actions are to be executed. Note that there is no need to execute 2761 a SUPAPolicy, since the event and failure have already occurred. 2762 Note: [1..n] means that this is a multi-valued property that has 2763 at least one (and possibly more) attributes. 2765 5.3.2.7. The Aggregation "SUPAHasPolicyClause" 2767 This is an optional aggregation that defines the set of 2768 SUPAPolicyClauses that are aggregated by this particular 2769 SUPAPolicyStructure instance. The semantics of this 2770 aggregation are defined by the SUPAHasPolicyClauseDetail 2771 association class. 2773 Every SUPAPolicyStructure object instance MUST aggregate at 2774 least one SUPAPolicyClause object instance. However, the 2775 converse is NOT true. For example, a SUPAPolicyClause could be 2776 instantiated and then stored for later use in a policy repository. 2777 Furthermore, the same SUPAPolicyClause could be used by zero or 2778 more SUPAPolicyStructure object instances at a given time. Thus, 2779 the multiplicity of this aggregation is defined as 0..1 on the 2780 aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the 2781 part (i.e., the SUPAPolicyClause side). This means that at 2782 least one SUPAPolicyClause MUST be aggregated by this 2783 SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may 2784 be aggregated by this particular SUPAPolicyStructure object. 2786 5.3.2.8. The Association Class "SUPAHasPolicyClauseDetail" 2788 This is an optional abstract association class, and defines the 2789 semantics of the SUPAHasPolicyClause aggregation. The attributes 2790 and/or relationships of this association class can be used to 2791 determine which SUPAPolicyClauses are aggregated by which 2792 SUPAPolicyStructure objects. 2794 Attributes will be added to this class at a later time. 2796 5.4. The Abstract Class "SUPAPolicyComponentStructure" 2798 This is a mandatory abstract class that is the superclass of all 2799 objects that represent different types of components of a 2800 SUPAPolicy. Different types of policies have different types of 2801 structural components. However, all of these are used in at least 2802 one type of policy. This class represents a convenient control 2803 point for defining characteristics and behavior that are common 2804 to objects that serve as components of a policy. 2806 Note that there are significant differences between the definition 2807 of this class, and its attributes, and the definition of the 2808 corresponding class (and its attributes) in [5]. 2810 5.4.1. SUPAPolicyComponentStructure Attributes 2812 No attributes are currently defined for the 2813 SUPAPolicyComponentStructure class. 2815 5.4.2. SUPAPolicyComponentStructure Relationships 2817 SUPAPolicyComponentStructure participates in a single relationship, 2818 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 2820 5.5. The Abstract Class "SUPAPolicyClause" 2822 This is a mandatory abstract class that separates the 2823 representation of a SUPAPolicy from its implementation. 2824 SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction 2825 is missing in [RFC3060], [RFC3460], [4], and [6]. This class is 2826 called PolicyStatement in [5], but the class and relationship 2827 definitions differ significantly from the corresponding designs 2828 in this document. 2830 A SUPAPolicyClause contains an individual or group of related 2831 functions that are used to define the content of a policy. More 2832 specifically, since the number and type of functions that make up 2833 a SUPAPolicyClause can vary, the decorator pattern is used, so 2834 that the contents of a SUPAPolicyClause can be adjusted 2835 dynamically at runtime without affecting other objects. 2837 This document defines two different types of policy clauses: 2838 SUPAEncodedClause (which is generic, and can be used by any 2839 type of policy), and SUPABooleanClause (which is also generic, 2840 but is typically used by SUPAECAPolicyRule objects). 2842 SUPAPolicyClauses are objects in their own right, which 2843 facilitates their reuse. SUPAPolicyClauses can aggregate a set 2844 of any of the subclasses of SUPAPolicyComponentDecorator, which 2845 was shown in Figure 10. These four subclasses provide four 2846 different ways to construct a SUPAPolicyClause: 2848 1) SUPAPolicyTerm, which enables constructing a {variable, 2849 operator, value} expression for building SUPAPolicyClauses 2850 2) SUPAEncodedClause, which enables policy clauses to be 2851 formed as an encoded object (e.g., to pass YANG or CLI code) 2852 3) SUPAPolicyCollection, which defines a collection of objects 2853 that requires further processing by the policy management 2854 system in order to be made into a SUPAPolicyClause 2855 4) SUPAECAComponent, which enables policy clauses to be formed 2856 using (reusable) Event, Condition, and/or Action objects 2858 SUPAPolicyClauses are aggregated by a SUPAPolicyStructure 2859 object, which enables all types of SUPAPolicies to uniformly be 2860 made up of one or more SUPAPolicyClauses. 2862 5.5.1. SUPAPolicyClause Attributes 2864 This section defines the attributes of the SUPAPolicyClause 2865 class, which are inherited by all SUPAPolicyClause subclasses. 2867 5.5.1.1. The Attribute "supaPolClauseExecStatus" 2869 This is an optional enumerated non-negative integer attribute. It 2870 defines whether this SUPAPolicyClause is currently in use and, if 2871 so, what its execution status is. This attribute can also be used 2872 to place this particular SUPAPolicyClause into a specific execution 2873 state, such as enabled (values 1-4), in test (value 5) or disabled 2874 (value 6). Values include: 2876 0: Unknown (an error state) 2877 1: Completed (i.e., successfully executed, but now idle) 2878 2: Working (i.e., in use and no errors reported) 2879 3: Not Working (i.e., in use, but errors have been reported) 2880 4: Available (i.e., could be used, but currently isn't) 2881 5: In Test (i.e., cannot be used as part of an OAM&P policy) 2882 6: Disabled (i.e., not available for use) 2884 Value 0 denotes an error that prevents this SUPAPolicyClause 2885 from being used. Value 1 means that this SUPAPolicyClause has 2886 successfully finished execution, and is now idle and available. 2887 Value 2 means that this SUPAPolicyClause is in use; in addition, 2888 this SUPAPolicyClause is working correctly. Value 3 is the same as 2889 value 2, except that this SUPAPolicyClause is not working 2890 correctly. Value 4 means that this SUPAPolicyClause is available, 2891 but not currently in use. Value 5 means that this SUPAPolicyClause 2892 is in a special test state. A test state signifies that it SHOULD 2893 NOT be used to evaluate OAM&P policies. A value of 6 means that 2894 this SUPAPolicyClause is unavailable for use. 2896 5.5.2. SUPAPolicyClause Relationships 2898 SUPAPolicyClause participates in a single relationship, 2899 SUPAHasPolicyClause, as defined in section 5.3.2.7. Note that 2900 SUPAPolicyClause uses the decorator pattern to "wrap" this object 2901 with instances of the (concrete) subclasses of the 2902 SUPAPolicyComponentDecorator object. 2904 5.6. The Concrete Class "SUPAEncodedClause" 2906 This is a mandatory concrete class that refines the behavior of a 2907 SUPAPolicyClause. 2909 This class defines a generalized extension mechanism for 2910 representing SUPAPolicyClauses that have not been modeled 2911 with other SUPAPolicy objects. Rather, the contents of the policy 2912 clause are directly encoded into the attributes of the 2913 SUPAEncodedClause. Hence, SUPAEncodedClause objects are reusable 2914 at the object level, whereas SUPABooleanClause clauses are reusable 2915 at the individual Boolean expression level. 2917 This class uses two of its attributes (supaEncodedClauseContent and 2918 supaEncodedClauseEncoding) for defining the content and type of 2919 encoding used in a given SUPAPolicyClause. The benefit of a 2920 SUPAEncodedClause is that it enables direct encoding of the text of 2921 the SUPAPolicyClause, without having the "overhead" of using other 2922 objects. However, note that while this method is efficient, it 2923 does not reuse other SUPAPolicy objects. 2925 5.6.1. SUPAEncodedClause Attributes 2927 This section defines the attributes of the SUPAEncodedClause class. 2929 5.6.1.1. The Attribute "supaEncodedClauseContent" 2931 This is a mandatory string attribute, and defines the content of 2932 this clause. It works with another class attribute, called 2933 supaEncodedClauseEncoding, which defines how to interpret the 2934 value of this attribute (e.g., as a string or reference). These 2935 two attributes form a tuple, and together enable a machine to 2936 understand the syntax and value of this object instance. 2938 5.6.1.2. The Attribute "supaEncodedClauseEncoding" 2940 This is a mandatory non-negative integer attribute, and defines 2941 how to interpret the value of this encoded clause. It works with 2942 another class attribute (supaEncodedClauseContent), which defines 2943 the content of the encoded clause. These two attributes form a 2944 tuple, and together enable a machine to understand the syntax and 2945 value of the encoded clause for the object instance of this class. 2946 Values include: 2948 0: undefined 2949 1: String 2950 2: GUID 2951 3: UUID 2952 4: URI 2953 5: FQDN 2954 6: FQPN 2956 5.6.1.3. The Attribute "supaEncodedClauseLanguage" 2958 This is mandatory non-negative integer attribute, and defines 2959 the type of language used in this encoded clause. Values include: 2961 0: undefined 2962 1: Text 2963 2: YANG 2964 3: XML 2965 4: CLI 2966 5: TL1 2968 5.6.1.4. The Attribute "supaEncodedClauseLang[0..n]" 2970 This is an optional array of string attribute that contains 2971 descriptive information about the type of language used in the 2972 supaEncodedClauseLanguage class attribute. Text is in comma 2973 separated value (i.e., vendorName, vendorVersion) format. 2975 5.6.1.5. The Attribute "supaEncodedClauseResponse" 2977 This is an optional Boolean attribute that emulates a Boolean 2978 response of this clause, so that it may be combined with other 2979 subclasses of the SUPAPolicyClause that provide a status as to 2980 their correctness and/or evaluation state. This enables this 2981 object to be used to construct more complex Boolean clauses. 2983 5.6.2. SUPAEncodedClause Relationships 2985 SUPAPolicyClause participates in a single inherited relationship, 2986 SUPAHasPolicyClause, as defined in section 5.3.2.7. 2988 5.7. The Abstract Class "SUPAPolicyComponentDecorator" 2990 This is a mandatory class, and is used to implement the decorator 2991 pattern. The decorator pattern enables all or part of one or more 2992 objects to "wrap" another concrete object. This means that any 2993 any concrete subclass of SUPAPolicyClause is wrapped by any 2994 concrete subclass of SUPAPolicyComponentDecorator, as shown in 2995 Figure 19 below. 2997 A 2998 +------------------------------+ 2999 | | 1..n 3000 | SUPAPolicyComponentStructure +--------+ 3001 | | | used to wrap 3002 +------------------------------+ | concrete 3003 / \ | subclasses of 3004 I | PolicyClause 3005 I | 3006 +---------------+--------------+ / \ 3007 I I A 3008 A I A I \ / 0..1 3009 +----------+---------+ +--------------+-----+---------+ 3010 | SUPAPolicyClause | | SUPAPolicyComponentDecorator | 3011 +----------+---------+ +--------------+---------------+ 3012 I I 3013 I I 3014 / \ / \ 3015 Concrete Subclasses, Concrete Subclasses 3016 (e.g., SUPAEncodedClause) (e.g., SUPAPolicyCollection) 3017 (object being wrapped) (wrapping object(s)) 3019 Figure 19. The PolicyComponent Decorator Pattern 3021 5.7.1. The Decorator Pattern 3023 Each SUPAPolicyComponentDecorator object HAS_A (i.e., wraps) a 3024 concrete instance of the SUPAPolicyClause object. This means that 3025 the SUPAPolicyComponentDecorator object has an instance variable 3026 that holds a reference to a SUPAPolicyClause object. Since the 3027 SUPAPolicyComponentDecorator object has the same interface as the 3028 SUPAPolicyClause object, the SUPAPolicyComponentDecorator object 3029 (and all of its subclasses) are transparent to clients of the 3030 SUPAPolicyClause object (and its subclasses). This means that 3031 SUPAPolicyComponentDecorator object instances can add attributes 3032 and/or methods to those of the concrete instance of the chosen 3033 subclass of SUPAPolicyClause. 3035 Figure 20 shows how this is done for methods. 20a shows the 3036 initial object to be wrapped; 20b shows SUPAPolicyCollection 3037 wrapping SUPAEncodedClause; 20c shows SUPAGenericDecoratedComponent 3038 wrapping SUPAPolicyCollection. 3040 +-------------------+ 3041 | SUPAEncodedClause | 3042 | eval() | 3043 +-------------------+ 3044 (a) Initial Object 3046 ===> 3047 +------------------------+ 3048 | SUPAPolicyCollection | 3049 | eval() | 3050 | +-------------------+ | 3051 | | SUPAEncodedClause | | 3052 | | eval() | | 3053 | +-------------------+ | 3054 +------------------------+ 3055 (b) SUPAPolicyCollection "wraps" SUPAEncodedClause 3057 ===> 3058 +--------------------------------+ 3059 | SUPAGenericDecoratedComponent | 3060 | eval() | 3061 | +-----------------------+ | 3062 | | SUPAPolicyCollection | | 3063 | | eval() | | 3064 | | +-------------------+ | | 3065 | | | SUPAEncodedClause | | | 3066 | | | eval() | | | 3067 | | +-------------------+ | | 3068 | +-----------------------+ | 3069 +--------------------------------+ 3070 (c) SUPAGenericDecoratedComponent "wraps" SUPAPolicyCollection 3072 Figure 20. Conceptual Depiction of eval() Decorated Method 3074 When eval() is called in the outermost object 3075 (SUPAGenericDecoratedComponent), it delegates to the eval() method 3076 of SUPAPolicyCollection, which in turn delegates to the eval() 3077 method of SUPAEncodedClause. This method executes and returns the 3078 results to SUPAPolicyCollection, which executes and returns the 3079 results to SUPAGenericDecoratedComponent, which executes and returns 3080 the final result. 3082 5.7.2. SUPAPolicyComponentDecorator Attributes 3084 Currently, there are two attributes defined for this class, which 3085 are described in the following subsections. Both attributes are 3086 used by subclasses to constrain the behavior of that subclass; 3087 they do **not** affect the relationship between the concrete 3088 subclass of SUPAPolicyComponentDecorator that is wrapping the 3089 concrete subclass of SUPAPolicyClause. 3091 This is different than the use of similar attributes defined in 3092 the SUPAHasDecoratedPolicyComponentDetail association class (which 3093 are used to constrain the relationship between the concrete 3094 subclass of SUPAPolicyClause and the concrete subclass of the 3095 SUPAPolicyComponentDecorator object that is wrapping it). 3096 Note that [2] does not define any attributes for this class. 3098 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" 3100 This is a mandatory non-negative enumerated integer that defines 3101 how to interpret each string in the supaPolCompConstraint class 3102 attribute. Values include: 3104 0: undefined 3105 1: OCL 2.4 3106 2: OCL 2.x 3107 3: OCL 1.x 3108 4: QVT 1.2 - Relations Language 3109 5: QVT 1.2 - Operational language 3110 6: Alloy 3111 7: English text 3113 Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the 3114 latest version as of this writing). QVT defines a set of languages 3115 (the two most powerful and useful are defined by enumerations 4 3116 and 5). Alloy is a language for describing constraints, and uses a 3117 SAT solver to guarantee correctness. Note that enumeration 7 3118 (English text) is not recommended (since it is informal, and hence, 3119 not verifiable), but included for completeness. 3121 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" 3123 This is a mandatory array of string attributes. Each attribute 3124 specifies a constraint to be applied using the encoding defined in 3125 the supaPolCompConstraintEncoding class attribute. This provides 3126 a more rigorous and flexible treatment of constraints than is 3127 possible in [RFC3460]. 3129 Note: [0..n] means that this is a multi-valued property that may 3130 have zero or more attributes. 3132 5.7.3. SUPAPolicyComponentDecorator Relationships 3134 One relationship is currently defined for this class, which is 3135 described in the following subsection. 3137 5.7.3.1. The Aggregation "SUPAHasDecoratedPolicyComponent" 3139 This is a mandatory aggregation, and is part of a decorator 3140 pattern. It is used to enable a concrete instance of a 3141 SUPAPolicyComponentDecorator to dynamically add behavior to a 3142 specific type of SUPAPolicyClause object. The semantics of this 3143 aggregation are defined by the 3144 SUPAHasDecoratedPolicyComponentDetail association class. 3146 5.7.3.2. The Association Class 3147 "SUPAHasDecoratedPolicyComponentDetail" 3149 This is a mandatory concrete association class, and defines the 3150 semantics of the SUPAHasDecoratedPolicyComponent aggregation. The 3151 purpose of this class is to use the Decorator pattern to determine 3152 which SUPAPolicyComponentDecorator object instances, if any, are 3153 required to augment the functionality of the concrete subclass of 3154 SUPAPolicyClause that is being used. 3156 Currently, there are two attributes defined for this class, which 3157 are described in the following subsections. Both attributes are 3158 used in this association class to constrain the **relationship** 3159 between the concrete subclass of SUPAPolicyComponentDecorator that 3160 is wrapping the concrete subclass of SUPAPolicyClause. Note that 3161 class attributes of SUPAPolicyComponentDecorator (see section 3162 5.9.2) only affect that specific subclass. 3164 5.7.3.2.1. The Attribute "supaDecoratedConstraintEncoding" 3166 This is a mandatory non-negative enumerated integer that defines 3167 how to interpret each string in the supaDecoratedConstraint class 3168 attribute. Values include: 3170 0: undefined 3171 1: OCL 2.4 3172 2: OCL 2.x 3173 3: OCL 1.x 3174 4: QVT 1.2 - Relations Language 3175 5: QVT 1.2 - Operational language 3176 6: Alloy 3177 7: English text 3179 Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the 3180 latest version as of this writing). QVT defines a set of languages 3181 (the two most powerful and useful are defined by enumerations 4 3182 and 5). Alloy is a language for describing constraints, and uses a 3183 SAT solver to guarantee correctness. Note that enumeration 7 3184 (English text) is not recommended (since it is informal, and hence, 3185 not verifiable), but included for completeness. 3187 5.7.3.2.2. The Attribute "supaDecoratedConstraint[0..n]" 3189 This is a mandatory array of string attributes. Its purpose is to 3190 collect a set of constraints to be applied to a decorated object. 3191 The interpretation of each constraint in the array is defined in 3192 the supaDecoratedConstraintsEncoding class attribute. 3193 Note: [0..n] means that this is a multi-valued property that may 3194 have zero or more attributes. 3196 5.7.4. Illustration of Constraints in the Decorator Pattern 3198 The following example will illustrate how the different constraints 3199 defined in sections 5.7.2 (class attribute constraints) and section 3200 5.7.3 (relationship constraints) can be used. 3202 Figure 21 builds a simple SUPAPolicyClause that has both types 3203 of relationships. 3205 A A 3206 +------------------+ 0..1 +----------------------------+ 3207 | | 1..n / \| | 3208 | SUPAPolicyClause +------+----- A +SUPAPolicyComponentDecorator| 3209 | | ^ \ /| | 3210 +---------+--------+ | +-----------+----------------+ 3211 I | I 3212 I | I 3213 C I | C I 3214 +--------+--------+ | +---------+----------+ 3215 |SUPAEncodedClause| | |SUPAPolicyCollection| 3216 +-----------------+ | +--------------------+ 3217 | 3218 C | 3219 +-----------------+-------------------+ 3220 |SUPAHasDecoratedPolicyComponentDetail| 3221 +-------------------------------------+ 3223 Figure 21. Constraints in the Decorator Pattern 3225 Figure 21 says that a SUPAPolicyClause, realized as a 3226 SUPAEncodedClause, is wrapped by a SUPAPolicyCollection object. 3227 The attributes in the SUPAPolicyComponentDecorator object are used 3228 to constrain the attributes in the SUPAPolicyCollection object, 3229 while the attributes in the SUPAHasDecoratedPolicyComponentDetail 3230 object are used to contrain the behavior of the aggregation 3231 (SUPAHasDecoratedPolicyComponent). For example, the attributes in 3232 the SUPAPolicyComponentDecorator object could restrict the data 3233 type and range of the components in the SUPAPolicyCollection, while 3234 the attributes in the SUPAHasDecoratedPolicyComponentDetail object 3235 could restrict which SUPAPolicyCollection objects are allowed to be 3236 used with which SUPAEncodedClauses. 3238 5.8. The Abstract Class "SUPAPolicyTerm" 3240 This is a mandatory abstract class that is the parent of 3241 SUPAPolicy objects that can be used to define a standard way to 3242 test or set the value of a variable. It does this by defining a 3243 3-tuple, in the form {variable, operator, value}, where each 3244 element of the 3-tuple is defined by a concrete subclass of the 3245 appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator, 3246 and SUPAPolicyValue classes, respectively). For example, a 3247 generic test or set of the value of a variable is expressed as: 3249 {variable, operator, value}. 3251 For event and condition clauses, this is typically as written above 3252 (e.g., does variable = value); for action clauses, it is typically 3253 written as (e.g., SET var to 1). A 3254 class diagram is shown in Figure 22. 3256 A 3257 +----------------+ 3258 | SUPAPolicyTerm | 3259 +--------+-------+ 3260 / \ 3261 I 3262 I 3263 I 3264 +-----------------+---+--------------------+ 3265 I I I 3266 I I I 3267 C I C I C I 3268 +--------+---------+ +--------+---------+ +-------+-------+ 3269 |SUPAPolicyVariable| |SUPAPolicyOperator| |SUPAPolicyValue| 3270 +------------------+ +------------------+ +---------------+ 3272 Figure 22. SUPAPolicyTerm Class Hierarchy 3274 Note that generic test and set expressions do not have to only use 3275 objects that are subclasses of SUPAPolicyTerm. For example, the 3276 polVendorDecoratedContent attribute of the 3277 SUPAGenericDecoratedComponent could be used as the variable (or the 3278 value) term of a get or set expression. 3280 Hence, the utility of the subclasses of SUPAPolicyTerm is in the 3281 ability of its subclasses to define a generic framework for 3282 implementing get and set expressions. This is in contrast to 3283 previous designs (e.g., [RFC3460] and [6]), which depended on 3284 defining a broad set of subclasses of PolicyVariable and 3285 PolicyValue. (Note that [4] does not have this generic capability). 3287 5.8.1. SUPAPolicyTerm Attributes 3289 Currently, SUPAPolicyTerm defines a single attribute, as described 3290 in the following subsection. Constraints on the subclasses of 3291 SUPAPolicyTerm can be applied in two different ways: 3293 1. use SUPAPolicyComponentDecorator attributes to constrain 3294 just that individual subclass, and/or 3295 2. use SUPAHasDecoratedPolicyComponentDetail association class 3296 attributes to constrain the relationship between the concrete 3297 subclass of SUPAPolicyClause and the concrete subclass of 3298 the SUPAPolicyTerm class 3300 5.8.1.1. The Attribute "supaPolTermIsNegated" 3302 This is a mandatory Boolean attribute. If the value of this 3303 attribute is true, then this particular SUPAPolicyTerm subclass 3304 (which represents a term) is negated; otherwise, it is not. 3306 5.8.2. SUPAPolicyTerm Relationships 3308 Currently, no dedicated relationships are defined for the 3309 SUPAPolicyTerm class (as there are in [RFC3460] and [6]) that 3310 aggregate policy variable and policy value objects into a policy 3311 rule). This is: 3313 1) to enable the subclasses of SUPAPolicyTerm to be used by 3314 other SUPAPolicyComponentDecorator objects, and 3315 2) because the decorator pattern replaces how such relationships 3316 were used in [RFC3460] and [6]. 3318 SUPAPolicyTerm, and its subclasses, inherit the 3319 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3320 section 5.7.3. 3322 5.9. The Concrete Class "SUPAPolicyVariable" 3324 This is a mandatory concrete class that defines information that 3325 forms a part of a SUPAPolicyClause. It specifies a concept or 3326 attribute that represents a variable, which should be compared to 3327 a value, as specifed in this SUPAPolicyClause. If it is used in 3328 a SUPAECAPolicyRule, then its value MAY be able to be changed at 3329 any time, including run-time, via use of the decorator pattern. 3330 This is not possible in previous designs ([RFC3460, [4], and [6]). 3332 The value of a SUPAPolicyVariable is typically compared to the 3333 value of a SUPAPolicyValue using the type of operator defined in 3334 a SUPAPolicyOperator. However, other objects may be used instead 3335 of a SUPAPolicyValue object, and other operators may be defined 3336 in addition to those defined in the SUPAPolicyOperator class. 3338 SUPAPolicyVariables are used to abstract the representation of a 3339 SUPAPolicyRule from its implementation. Some SUPAPolicyVariables 3340 are restricted in the values and/or the data type that they may 3341 be assigned. For example, port numbers cannot be negative, and 3342 they cannot be floating-point numbers. These and other constraints 3343 may be defined in two different ways: 3345 1. use SUPAPolicyComponentDecorator attributes to constrain 3346 just that individual subclass, and/or 3347 2. use SUPAHasDecoratedPolicyComponentDetail association class 3348 attributes to constrain the relationship between the concrete 3349 subclass of SUPAPolicyClause and the concrete subclass of 3350 the SUPAPolicyVariable class 3352 Please refer to the examples in section 7, which show how to 3353 restrict the value, data type, range, and other semantics of the 3354 SUPAPolicyVariable when used in a SUPAPolicyClause. 3356 5.9.1. Problems with the RFC3460 Version of PolicyValue 3358 Please see Appendix A for a detailed comparison. 3360 5.9.2. SUPAPolicyVariable Attributes 3362 SUPAPolicyVariable defines one attribute, as described below. 3364 5.9.2.1. The Attribute "supaPolVarName" 3366 This is an optional string attribute that contains the name of 3367 this SUPAPolicyVariable. This variable name forms part of the 3368 {variable, operator, value} canonical form of a SUPAPolicyClause. 3370 5.9.3. SUPAPolicyVariable Relationships 3372 Currently, no relationships are defined for the SUPAPolicyVariable 3373 class (note that the decorator pattern obviates the need for 3374 relationships such as those in [RFC3460] and [6]). 3375 SUPAPolicyVariable, and its subclasses, inherit the 3376 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3377 section 5.7.3. 3379 5.10. The Concrete Class "SUPAPolicyOperator" 3381 This is a mandatory concrete class for modeling different types of 3382 operators that are used in a SUPAPolicyClause. 3384 The restriction of the type of operator used in a SUPAPolicyClause 3385 restricts the semantics that can be expressed in that 3386 SUPAPolicyClause. It is typically used with SUPAPolicyVariables 3387 and SUPAPolicyValue to form a SUPAPolicyClause. 3389 5.10.1. Problems with the RFC3460 Version 3391 Please see Appendix A for a detailed comparison. 3393 5.10.2. SUPAPolicyOperator Attributes 3395 Currently, SUPAPolicyOperator defines a single generic attribute, 3396 as described below. 3398 5.10.2.1. The Attribute "supaPolOpType" 3400 This is a mandatory non-negative enumerated integer that specifies 3401 the various types of operators that are allowed to be used in this 3402 particular SUPAPolicyClause. Values include: 3404 0: Unknown 3405 1: Greater than 3406 2: Greater than or equal to 3407 3: Less than 3408 4: Less than or equal to 3409 5: Equal to 3410 6: Not equal to 3411 7: IN 3412 8: NOT IN 3413 9: SET 3414 10: CLEAR 3415 11: BETWEEN (inclusive) 3417 Note that 0 is an unacceptable value. Its purpose is to support 3418 dynamically building a SUPAPolicyClause by enabling the 3419 application to set the value of this attribute to a standard 3420 default value if the real value is not yet known. 3422 Additional operators may be defined in future work. For example, 3423 if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from 3424 include structured objects, then "deep" versions of operators 3425 1-6 could also be defined. In this case, values 1-6 will be 3426 edited to explicitly indicate that they perform "shallow" 3427 comparison operations. 3429 5.10.3. SUPAPolicyOperator Relationships 3431 Currently, no relationships are defined for the SUPAPolicyOperator 3432 class (note that the decorator pattern obviates the need for 3433 relationships such as those in [6]). SUPAPolicyOperator, and its 3434 subclasses, inherit the SUPAHasDecoratedPolicyComponent 3435 aggregation, which was defined in section 5.7.3. 3437 Please refer to the examples in section 7, which show how to 3438 restrict the value, data type, range, and other semantics of the 3439 SUPAPolicyOperator when used in a SUPAPolicyClause. 3441 5.11. The Concrete Class "SUPAPolicyValue" 3443 The SUPAPolicyValue class is a mandatory concrete class for 3444 modeling different types of values and constants that occur in a 3445 SUPAPolicyClause. 3447 SUPAPolicyValues are used to abstract the representation of a 3448 SUPAPolicyRule from its implementation. Therefore, the design of 3449 SUPAPolicyValues depends on two important factors. First, just as 3450 with SUPAPolicyVariables (see Section 5.11), some types of 3451 SUPAPolicyValues are restricted in the values and/or the data 3452 type that they may be assigned. Second, there is a high likelihood 3453 that specific applications will need to use their own variables 3454 that have specific meaning to a particular application. 3456 In general, there are two ways to apply constraints to an object 3457 instance of a SUPAPolicyValue: 3459 1. use SUPAPolicyComponentDecorator attributes to constrain 3460 just that individual subclass, and/or 3461 2. use SUPAHasDecoratedPolicyComponentDetail association class 3462 attributes to constrain the relationship between the concrete 3463 subclass of SUPAPolicyClause and the concrete subclass of 3464 the SUPAPolicyValue class 3466 The value of a SUPAPolicyValue is typically compared to the value 3467 of a SUPAPolicyVariable using the type of operator defined in 3468 a SUPAPolicyOperator. However, other objects may be used instead 3469 of a SUPAPolicyVariable object, and other operators may be defined 3470 in addition to those defined in the SUPAPolicyOperator class. 3472 5.11.1. Problems with the RFC3460 Version of PolicyValue 3474 Please see Appendix A for a detailed comparison. 3476 5.11.2. SUPAPolicyValue Attributes 3478 Currently, SUPAPolicyValue defines two generic attributes, as 3479 described below. 3481 5.11.2.1. The Attribute "supaPolValContent[0..n]" 3483 This is a mandatory attribute that defines an array of strings. 3484 The array contains the value(s) of this SUPAPolicyValue object 3485 instance. Its data type is defined by the supaPolValEncoding 3486 class attribute. 3487 Note: [0..n] means that this is a multi-valued property that has 3488 zero or more attributes. 3490 5.11.2.2. The Attribute "supaPolValEncoding" 3492 This is a mandatory string attribute that contains the data type 3493 of the SUPAPolicyValue object instance. Its value is defined by 3494 the supaPolValContent class attribute. Values include: 3496 0: Undefined 3497 1: String 3498 2: Integer 3499 3: Boolean 3500 4: Floating Point 3501 5: DateTime 3502 6: GUID 3503 7: UUID 3504 8: URI 3505 9: FQDN 3506 10: FQPN 3507 11: NULL 3509 A string is a sequence of zero or more characters. An Integer is 3510 a whole number (e.g., it has no fractional part). A Boolean 3511 represents the values TRUE and FALSE. A floating point number may 3512 contain fractional values, as well as an exponent. A DateTime 3513 represents a value that has a date and/or a time component (as in 3514 the Java or Python libraries). A NULL explicitly models the lack 3515 of a value. 3517 5.11.3. SUPAPolicyValue Relationships 3519 Currently, no relationships are defined for the SUPAPolicyValue 3520 class (note that the decorator pattern obviates the need for 3521 relationships such as those in [6]). SUPAPolicyValue, and its 3522 subclasses, inherit the SUPAHasDecoratedPolicyComponent 3523 aggregation, which was defined in section 5.7.3. 3525 Please refer to the examples in section 7, which show how to 3526 restrict the value, data type, range, and other semantics of the 3527 SUPAPolicyValue when used in a SUPAPolicyClause. 3529 5.12. The Concrete Class "SUPAGenericDecoratedComponent" 3531 A SUPAGenericDecoratedComponent enables a custom, vendor-specific 3532 object to be defined and used in a SUPAPolicyClause. This class 3533 was derived from [2], but is not present in [RFC3460], [4], [5], 3534 or [6]. 3536 This should not be confused with the SUPAEncodedClause class. The 3537 SUPAGenericDecoratedComponent class represents a single, atomic, 3538 vendor-specific object that defines a **portion** of a 3539 SUPAPolicyClause, whereas a SUPAEncodedClause, which may or 3540 may not be vendor-specific, represents an **entire** 3541 SUPAPolicyClause. 3543 5.12.1. SUPAGenericDecoratedComponent Attributes 3545 Currently, SUPAGenericDecoratedComponent defines two generic 3546 attributes, as described below. 3548 5.12.1.1. The Attribute "supaVendorDecoratedCompContent[0..n]" 3550 This is a mandatory attribute that defines an array of strings. 3551 This array contains the value(s) of the 3552 SUPAGenericDecoratedComponent object instance. Its data type is 3553 defined by the supaVendorDecoratedEncoding class attribute. 3554 Note: [0..n] means that this is a multi-valued property that has 3555 zero or more attributes. 3557 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 3559 This is a mandatory integer attribute that defines the format of 3560 the supaVendorDecoratedContent class attribute. Values include: 3562 0: undefined 3563 1: String 3564 2: Integer 3565 3: Boolean 3566 4: Floating Point 3567 5: DateTime 3568 6: GUID 3569 7: UUID 3570 8: URI 3571 9: FQDN 3572 10: FQPN 3573 11: NULL 3575 A string is a sequence of zero or more characters. An Integer is 3576 a whole number (e.g., it has no fractional part). A Boolean 3577 represents the values TRUE and FALSE. A floating point number may 3578 contain fractional values, as well as an exponent. A DateTime 3579 represents a value that has a date and/or a time component (as in 3580 the Java or Python libraries). A NULL explicitly models the lack 3581 of a value. 3583 5.12.2. SUPAGenericDecoratedComponent Relationships 3585 Currently, no relationships are defiend for the 3586 SUPAGenericDecoratedComponent class (note that the decorator 3587 pattern obviates the need for relationships such as those in [6]). 3588 SUPAGenericDecoratedComponent participates in a single relationship, 3589 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 3591 5.13. The Concrete Class "SUPAPolicyCollection" 3593 A SUPAPolicyCollection is an optional concrete class that enables 3594 a collection (e.g., set, bag, or other, more complex, collections 3595 of elements) of **arbitrary objects** to be defined and used as 3596 part of a SUPAPolicyClause. This class was derived from [2], but 3597 is not present in [RFC3460], [4], [5], or [6]. 3599 5.13.1. Motivation 3601 One of the problems with ECA policy rules is when a set of events 3602 or conditions needs to be tested. For example, if a set of events 3603 is received, the policy system may need to wait for patterns of 3604 events to emerge (e.g., any number of Events of type A, followed 3605 by either one event of type B or two events of type Event C). 3606 Similarly, a set of conditions, testing the value of an attribute, 3607 may need to be performed. Both of these represent behavior 3608 similar to a set of if-then-else statements or a switch statement. 3610 It is typically not desirable for the policy system to represent 3611 each choice in such conditions as its own policy clause (i.e., a 3612 3-tuple), as this creates object explosion and poor performance. 3613 Furthermore, in these cases, it is often required to have a set of 3614 complex logic to be executed, where the logic varies according to 3615 the particular event or condition that was selected. It is much 3616 too complex to represent this using separate objects, especially 3617 when the logic is application- and/or vendor-specific. 3619 However, recall that one of the goals of this document was to 3620 facilitate the machine-driven construction of policies. Therefore, 3621 a solution to this problem is needed. 3623 5.13.2. Solution 3625 Therefore, this document defines the concept of a collection of 3626 entities, called a SUPAPolicyCollection. Conceptually, the items 3627 to be collected (e.g., events or conditions) are aggregated in 3628 one or more SUPAPolicyCollection objects of the appropriate type. 3629 Another optional SUPAPolicyCollection object could be used to 3630 aggregate logic blocks (including SUPAPolicies) to execute. 3631 Once finished, all appropriate SUPAPolicyCollection objects are 3632 sent to an external system for evaluation. 3634 The computation(s) represented by the SUPAPolicyCollection may be 3635 part of a larger SUPAPolicyClause, since SUPAPolicyCollection is a 3636 subclass of SUPAPolicyComponentDecorator, and can be used to 3637 decorate a SUPAPolicyClause. Therefore, the external system is 3638 responsible for providing a Boolean TRUE or FALSE return value, so 3639 that the policy system can use that value to represent the 3640 computation of the function(s) performed in the 3641 SUPAPolicyCollection in a Boolean clause. 3643 5.13.3. SUPAPolicyCollection Attributes 3645 Currently, SUPAGenericDecoratedComponent defines five attributes, 3646 as described below. 3648 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 3650 This is an optional attribute that defines an array of strings. 3651 Each string in the array identifies a domain-suitable identifier of 3652 an object that is collected by this SUPAPolicyCollection instance. 3653 Note: [0..n] means that this is a multi-valued property that has 3654 zero or more attributes. 3656 5.13.3.2. The Attribute "supaPolCollectionEncoding" 3658 This is an optional non-negative enumerated integer that defines 3659 the data type of the content of this collection instance. Values 3660 include: 3662 0: undefined 3663 1: by regex (regular expression) 3664 2: by URI 3666 For example, if the value of this attribute is 1, then each of 3667 the strings in the supaPolCollectionContent attribute represent 3668 a regex that contains all or part of a string to match the class 3669 name of the object that is to be collected by this instance of 3670 a SUPAPolicyCollection class. 3672 5.13.3.3. The Attribute "supaPolCollectionFunction" 3674 This is an optional non-negative enumerated integer that defines 3675 the function of this collection instance. Values include: 3677 0: undefined 3678 1: event collection 3679 2: condition collection 3680 3: action collection 3681 4: logic collection 3683 Values 1-3 define a collection of objects that are to be used to 3684 populate the event, condition, or action clauses, respectively, of 3685 a SUPAECAPolicyRule. A value of 4 indicates that this collection 3686 contains objects that define logic for processing a SUPAPolicy. 3688 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" 3690 This is an optional Boolean attribute. If the value of this 3691 attribute is TRUE, then all elements in this instance of this 3692 SUPAPolicyCollection are ordered. 3694 5.13.3.5. The Attribute "supaPolCollectionType" 3696 This is an optional non-negative enumerated integer that defines 3697 the type of collection that this instance is. Values include: 3699 0: undefined 3700 1: set 3701 2: bag (e.g., multi-set) 3702 3: dictionary (e.g., associative array) 3704 A set is an unordered collection of elements that MUST NOT have 3705 duplicates. A bag is an unordered collection of elements; it MAY 3706 also have duplicates. A dictionary is a table that associates a 3707 key with a value. 3709 Sets have a number of important functions, including: 3711 o membership: returns TRUE if the element being tested is 3712 in the set, and FALSE otherwise 3713 o subset: returns TRUE if all elements in the first set 3714 are also in the second set 3715 o union: returns all elements from both sets with no 3716 duplicates 3717 o intersection: returns all elements that are in both sets 3718 with no duplicates 3719 o difference: returns all elements in the first set that 3720 are not in the second set 3722 Bags have a number of important functions in addition to the 3723 functions defined for sets (note that while the above set of 3724 functions for a set and a bag are the same, a bag is a different 3725 data type than a set): 3727 o multiplicity: returns the number of occurrences of an 3728 element in the bag 3729 o count: returns the number of all items, including 3730 duplicates 3731 o countDistinct: returns the number of items, where all 3732 duplicates are ignored 3734 A dictionary is an unordered set of key:value pairs, where each 3735 key is unique within a given dictionary. The combination of a 3736 key and a value is called an item. The format of an item is 3737 defined as one element (the key) followed by a colon followed 3738 by a second element (the value). Each item in a set of items is 3739 separated by a comma. Keys MUST NOT be NULL; values MAY be NULL. 3741 An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}. 3742 An example of a null dictionary is simply {}. 3744 5.13.4. SUPAPolicyCollection Relationships 3746 Currently, no relationships are defined for the 3747 SUPAGenericDecoratedComponent class (note that the decorator 3748 pattern obviates the need for relationships such as those in [6]). 3749 SUPAPolicyCollection participates in a single relationship, 3750 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 3752 5.14. The Concrete Class "SUPAPolicySource" 3754 This is an optional class that defines a set of managed entities 3755 that authored, or are otherwise responsible for, this 3756 SUPAPolicyRule. Note that a SUPAPolicySource does NOT 3757 evaluate or execute SUPAPolicies. Its primary use is for 3758 auditability and the implementation of deontic and/or alethic logic. 3759 A class diagram is shown in Figure 12. 3761 A SUPAPolicySource SHOULD be mapped to a role or set of roles 3762 (e.g., using the role-object pattern [11]). This enables 3763 role-based access control to be used to restrict which entities 3764 can author a given policy. Note that Role is a type of 3765 SUPAPolicyMetadata. 3767 5.14.1. SUPAPolicySource Attributes 3769 Currently, no attributes are defined for this class. 3771 5.14.2. SUPAPolicySource Relationships 3773 SUPAPolicySource participates in a single relationship, 3774 SUPAHasPolicySource, as defined in section 5.3.2.1. 3775 SUPAPolicySource, and its subclasses, inherit the 3776 SUPAHasDecoratedPolicyComponent aggregation, which was 3777 defined in section 5.7.3. 3779 5.15. The Concrete Class "SUPAPolicyTarget" 3781 This is an optional class that defines a set of managed entities 3782 that a SUPAPolicy is applied to. Figure 12 shows a class diagram 3783 of the SUPAPolicyTarget. 3785 A managed object must satisfy two conditions in order to be defined 3786 as a SUPAPolicyTarget. First, the set of managed entities that are 3787 to be affected by the SUPAPolicy must all agree to play the role of 3788 a SUPAPolicyTarget. In general, a managed entity may or may not be 3789 in a state that enables SUPAPolicies to be applied to it to change 3790 its state; hence, a negotiation process may need to occur to enable 3791 the SUPAPolicyTarget to signal when it is willing to have 3792 SUPAPolicies applied to it. Second, a SUPAPolicyTarget must be able 3793 to process (directly or with the aid of a proxy) SUPAPolicies. 3795 If a proposed SUPAPolicyTarget meets both of these conditions, it 3796 SHOULD set its supaPolicyTargetEnabled Boolean attribute to a 3797 value of TRUE. 3799 A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the 3800 role-object pattern). This enables role-based access control to 3801 be used to restrict which entities can author a given policy. 3802 Note that Role is a type of SUPAPolicyMetadata. 3804 5.15.1. SUPAPolicyTarget Attributes 3806 Currently, no attributes are defined for the SUPAPolicyTarget 3807 class. 3809 5.15.2. SUPAPolicyTarget Relationships 3811 SUPAPolicyTarget participates in a single relationship, 3812 SUPAHasPolicyTarget, as defined in section 5.3.2.3. 3814 5.16. The Abstract Class "SUPAPolicyMetadata" 3816 Metadata is information that describes and/or prescribes 3817 characteristics and behavior of another object that is **not** 3818 an inherent, distinguishing characteristic or behavior of that 3819 object (otherwise, it would be an integral part of that object). 3821 For example, a socialSecurityNumber attribute should not be part 3822 of a generic Person class. First, most countries in the world do 3823 not know what a social security number is, much less use them. 3824 Second, a person is not created with a social security number; 3825 rather, a social security number is used to track people for 3826 administering social benefits, though it is also used as a form 3827 of identification. 3829 Continuing the example, a better way to add this capability to a 3830 model would be to have a generic Identification class, then 3831 define a SocialSecurityNumber subclass, populate it as necessary, 3832 and then define a composition between a Person and it (this is a 3833 composition because social security numbers are not reused). 3835 Since social security numbers are given to US citizens, permanent 3836 residents, and temporary working residents, and because it is 3837 also used to administer benefits, the composition is realized 3838 as an association class to define how it is being used. 3840 An example of descriptive metadata for network elements would be 3841 documentation about best current usage practices (this could also 3842 be in the form of a reference). An example of prescriptive 3843 metadata for network elements would be the definition of a time 3844 period during which specific types of operations are allowable. 3846 This is an optional class that defines the top of a hierarchy of 3847 model elements that are used to define different types of metadata 3848 that can be applied to policy and policy component objects. This 3849 enables common metadata to be defined as objects and then reused 3850 when the metadata are applicable. One way to control whether 3851 SUPAPolicyMetadata objects are reused is by using the attributes 3852 of the SUPAHasPolicyMetadataDetail association class. 3854 It is recommended that this class, along with its 3855 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator 3856 subclasses, be used as part of a conformant implementation. It is 3857 defined to be optional, since metadata is not strictly required. 3858 However, metadata can help specify and describe SUPAPolicyObject 3859 entities, and can also be used to drive dynamic behavior. 3861 5.16.1. SUPAPolicyMetadata Attributes 3863 This section defines the attributes of the SUPAPolicyMetadata 3864 class. 3866 5.16.1.1. The Attribute "supaPolMetadataDescription" 3868 This is an optional string attribute that defines a free-form 3869 textual description of this metadata object. 3871 5.16.1.2. The Attribute "supaPolMetadataIDContent" 3873 This is a mandatory string attribute that represents part of the 3874 object identifier of an instance of this class. It defines the 3875 content of the object identifier. It works with another class 3876 attribute, called supaPolMetadataIDEncoding, which defines how to 3877 interpret this attribute. These two attributes form a tuple, 3878 and together enable a machine to understand the syntax and value 3879 of an object identifier for the object instance of this class. 3881 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" 3883 This is an optional non-zero enumerated integer attribute that 3884 represents part of the object identifier of an instance of this 3885 class. It defines the format of the object identifier. It works 3886 with another class attribute, called supaPolMetadataIDContent, 3887 which defines the content of the object ID. 3889 These two attributes form a tuple, and together enable a machine 3890 to understand the syntax and value of an object identifier for 3891 the object instance of this class. The supaPolMetadataIDEncoding 3892 attribute is mapped to the following values: 3894 0: undefined 3895 1: GUID 3896 2: UUID 3897 3: URI 3898 4: FQDN 3899 5: FQPN 3901 5.16.1.4. The Attribute "supaPolMetadataName" 3903 This is an optional string attribute that defines the name of this 3904 SUPAPolicyMetadata object. 3906 5.16.2. SUPAPolicyMetadata Relationships 3908 SUPAPolicyMetadata participates in a single aggregation, which is 3909 defined in the following subsections. 3911 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" 3913 This is a mandatory aggregation that defines the set of 3914 SUPAPolicyMetadata that are aggregated by this particular 3915 SUPAPolicyObject. It is recommended that this aggregation be used 3916 as part of a conformant implementation. 3918 The multiplicity of this relationship is defined as 0..n on the 3919 aggregate (SUPAPolicyObject) side, and 0..n on the part 3920 (SUPAPolicyMetadata) side. This means that this relationship is 3921 optional. The semantics of this aggregation are implemented using 3922 the SUPAHasPolicyMetadataDetail association class. 3924 5.16.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail" 3926 This is a mandatory concrete association class, and defines the 3927 semantics of the SUPAHasPolicyMetadata aggregation. Its purpose is 3928 to determine which SUPAPolicyMetadata object instances should be 3929 attached to which particular object instances of the 3930 SUPAPolicyObject class. This is done by using the attributes and 3931 relationships of the SUPAPolicyMetadataDetail class to constrain 3932 which SUPAPolicyMetadata objects can be aggregated by which 3933 particular SUPAPolicyObject instances. It is recommended that this 3934 association class be used as part of a conformant implementation. 3936 5.16.2.2.1. The Attribute "supaPolMetadataIsApplicable" 3938 This is an optional Boolean attribute. If the value of this 3939 attribute is TRUE, then the SUPAPolicyMetadata object(s) of this 3940 particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated 3941 by this particular SUPAPolicyObject. 3943 5.16.2.2.2. The Attribute "supaPolMetadataConstraintEncoding" 3945 This is an optional non-negative enumerated integer that defines 3946 how to interpret each string in the supaPolMetadataConstraint 3947 class attribute. Values include: 3949 0: undefined 3950 1: OCL 2.4 3951 2: OCL 2.x 3952 3: OCL 1.x 3953 4: QVT 1.2 - Relations Language 3954 5: QVT 1.2 - Operational language 3955 6: Alloy 3956 7: English text 3958 Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the 3959 latest version as of this writing). QVT defines a set of languages 3960 (the two most powerful and useful are defined by enumerations 4 3961 and 5). Alloy is a language for describing constraints, and uses a 3962 SAT solver to guarantee correctness. Note that enumeration 7 3963 (English text) is not recommended (since it is informal, and hence, 3964 not verifiable), but included for completeness. 3966 If this class is instantiated, then this attribute SHOULD also be 3967 instantiated, and should be part of a conformant implementation. 3969 5.16.2.2.3. The Attribute "supaPolMetadataConstraint[0..n]" 3971 This is an optional array of string attributes. Each attribute 3972 specifies a constraint to be applied using the format identified 3973 by the value of the supaPolMetadataPolicyConstraintEncoding class 3974 attribute. This provides a more rigorous and flexible treatment of 3975 constraints than is possible in [RFC3460]. 3977 If this class is instantiated, then this attribute SHOULD also be 3978 instantiated, and should be part of a conformant implementation. 3979 Note: [0..n] means that this is a multi-valued property that has 3980 zero or more attributes. 3982 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" 3984 This is an optional concrete class. It defines an object that will 3985 be wrapped by concrete instances of the SUPAPolicyMetadataDecorator 3986 class. It can be viewed as a "carrier" for metadata that will be 3987 attached to a subclass of SUPAPolicyObject. Since the decorator 3988 pattern is used, any number of concrete subclasses of the 3989 SUPAPolicyMetadataDecorator class can wrap an instance of the 3990 SUPAPolicyConcreteMetadata class. 3992 It is recommended that this class be used as part of a conformant 3993 implementation. 3995 5.17.1. SUPAPolicyConcreteMetadata Attributes 3997 Currently, two attributes are defined for the 3998 SUPAPolicyConcreteMetadata class, and are described in the 3999 following subsections. 4001 5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" 4003 This is an optional attribute. Its data type should be able to 4004 express a date and a time. This attribute defines the ending 4005 date and time that this Metadata object is valid for. 4007 5.17.1.2. The Attribute "supaPolMDValidPeriodStart" 4009 This is an optional attribute. Its data type should be able to 4010 express a date and a time. This attribute defines the starting 4011 date and time that this Metadata object is valid for. 4013 5.17.2. SUPAPolicyConcreteMetadata Relationships 4015 This class inherits the relationships of the SUPAPolicyMetadata 4016 class; see section 5.16.2. It can also be used by subclasses of 4017 the SUPAPolicyMetadataDecorator class, and hence, can participate 4018 in the SUPAHasMetadataDecorator aggregation; see section 5.18.2. 4020 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" 4022 This is an optional class, and is used to implement the decorator 4023 pattern (see section 5.7.1.) for metadata objects. This pattern 4024 enables all or part of one or more SUPAPolicyMetadataDecorator 4025 subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance. 4027 It is recommended that this class be used as part of a conformant 4028 implementation. 4030 5.18.1. SUPAPolicyMetadataDecorator Attributes 4032 Currently, no attributes are defined for the 4033 SUPAPolicyMetadataDecorator class. 4035 5.18.2. SUPAPolicyMetadataDecorator Relationships 4037 This class inherits the relationships of the SUPAPolicyMetadata 4038 class; see section 5.16.2. It also defines a single aggregation, 4039 SUPAHasMetadataDecorator, which is used to implement the decorator 4040 pattern, as described in the following subsections. 4042 5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" 4044 This is an optional aggregation, and is part of a decorator 4045 pattern. It is used to enable a concrete instance of a 4046 SUPAPolicyMetadataDecorator to dynamically add behavior to a 4047 SUPAPolicyConcreteMetadata object instance. The semantics of this 4048 aggregation are defined by the SUPAHasMetadataDecoratorDetail 4049 association class. 4051 It is recommended that this aggregation be part of a conformant 4052 implementation. 4054 The multiplicity of this aggregation is 0..1 on the aggregate 4055 (SUPAPolicyMetadataDecorator) side and 1..n on the part 4056 (SUPAPolicyMetadata) side. This means that if this aggregation is 4057 defined, then at least one SUPAPolicyMetadata object (e.g., a 4058 concrete subclass of SUPAPolicyMetadataDecorator) must also be 4059 instantiated and wrapped by this SUPAPolicyConcreteMetadata object 4060 instance. The semantics of this aggregation are defined by the 4061 SUPAHasMetadataDecoratorDetail association class. 4063 5.18.2.2. The Association Class "SUPAHasMetadataDecoratorDetail" 4065 This is an optional concrete association class, and defines the 4066 semantics of the SUPAHasMetadataDecorator aggregation. The purpose 4067 of this class is to use the Decorator pattern to determine 4068 which SUPAPolicyMetadataDecorator object instances, if any, are 4069 required to augment the functionality of the 4070 SUPAPolicyConcreteMetadata object instance that is being used. 4072 It is recommended that this association class be part of a 4073 conformant implementation. 4075 Attributes for this association class will be defined in a future 4076 version of this document. 4078 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" 4080 This is an optional concrete class that defines access control 4081 information, in the form of metadata, that can be added to a 4082 SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata 4083 aggregation (see section 5.2.2.). This enables all or part of a 4084 standardized description and/or specification of access control 4085 for a given SUPAPolicyObject to be easily changed at runtime by 4086 wrapping an object instance of the SUPAPolicyConcreteMetadata 4087 class (or its subclass) with all or part of this object, and then 4088 adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata 4089 object instance. 4091 5.19.1. SUPAPolicyAccessMetadataDef Attributes 4093 Currently, the SUPAPolicyAccessMetadataDef class defines three 4094 attributes; these are described in the following subsections. 4096 5.19.1.1. The Attribute "supaPolAccessPrivilegeDef" 4098 This is an optional non-negative enumerated integer attribute. It 4099 specifies the access privileges that external Applications have 4100 when interacting with a specific SUPAPolicyObject that is adorned 4101 with an instance of this SUPAPolicyAccessMetadataDef object. This 4102 enables the management system to control, in a consistent manner, 4103 the set of operations that external Applications have for 4104 SUPAPolicies and components of SUPAPolicies. Values include: 4106 0: undefined 4107 1: read only (for all policy components) 4108 2: read and write (for all policy components) 4109 3: privileges are specified by an external MAC model 4110 4: privileges are specified by an external DAC model 4111 5: privileges are specified by an external RBAC model 4112 6: privileges are specified by an external ABAC model 4113 7: privileges are specified by an external custom model 4115 Values 1 and 2 apply to ALL SUPAPolicyObject instances that are 4116 adorned with this SUPAPolicyConcreteMetadata object instance; 4117 these two settings are "all-or-nothing" settings, and are included 4118 for ease of use. 4120 Values 3-7 indicate that a formal external access control model is 4121 used. The name of this model, and its location, are specified in 4122 two other class attributes, called supaPolAccessPrivilegeModelName 4123 and supaPolAccessPrivilegeModelRef. MAC, DAC, RBAC, and ABAC 4124 (values 3-6 stand for Mandatory Access Control, Discretionary 4125 Access Control, Role-Based Access Control, and Attribute-Based 4126 Access Control, respectively. A value of 7 indicates that a formal 4127 external model that is not MAC, DAC, RBAC, or ABAC is used. 4129 5.19.1.2. The Attribute "supaPolAccessPrivilegeModelName" 4131 This is an optional string attribute that contains the name of 4132 the access control model being used. If the value of the 4133 supaPolAccessPrivilegeDef is 0-2, then the value of this attribute 4134 is not applicable. Otherwise, the text in this class attribute 4135 should be interpreted according to the value of the 4136 supaPolAccessPrivilegeModelRef class attribute. 4138 5.19.1.3. The Attribute "supaPolAccessPrivilegeModelRef" 4140 This is an optional non-negative enumerated integer attribute 4141 that defines the data type of the supaPolAccessPrivilegeModelName 4142 attribute. If the value of the supaPolAccessPrivilegeDef class 4143 attribute is 0-2, then the value of this attribute is not 4144 applicable. Otherwise, the value of this class attribute defines 4145 how to interpret the text in the supaPolAccessPrivilegeModelRef 4146 class attribute. Values include: 4148 0: Undefined 4149 1: URI 4150 2: GUID 4151 3: UUID 4152 4: FQDN 4153 5: FQPN 4155 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" 4157 This is an optional concrete class that defines versioning 4158 information, in the form of metadata, that can be added to a 4159 SUPAPolicyObject. This enables all or part of a standardized 4160 description and/or specification of version information for a 4161 given SUPAPolicyObject to be easily changed at runtime by 4162 wrapping an object instance of the SUPAPolicyConcreteMetadata 4163 class (or its subclass) with all or part of this object. 4165 5.20.1. SUPAPolicyVersionMetadataDef Attributes 4167 Version information is defined in a generic format based on the 4168 Semantic Versioning Specification [18] as follows: 4170 ..[][] 4172 where the first three components (major, minor, and patch) MUST be 4173 present, and the latter two components (pre-release and build- 4174 metadata) MAY be present. A version number MUST take the form 4175 .., where , , and are 4176 each non-negative integers that MUST NOT contain leading zeros. 4177 In addition, the value of each of these three elements MUST 4178 increase numerically. 4180 In this approach: 4182 o supaVersionMajor denotes a new release; this number MUST be 4183 incremented when either changes are introduced that are not 4184 backwards-compatible, and/or new functionality not previously 4185 present is introduced 4187 o supaVersionMinor denotes a minor release; this number MUST be 4188 incremented when new features and/or bug fixes to a major 4189 release that are backwards-compatible are introduced, and/or 4190 if any features are marked as deprecated 4191 o supaVersionPatch denotes a version that consists ONLY of bug 4192 fixes, and MUST be incremented when these bug fixes are Not 4193 backwards-compatible 4195 When multiple versions exist, the following rules define their 4196 precedence: 4198 1. Precedence MUST be calculated by separating the version into 4199 major, minor, patch, and pre-release identifiers, in that 4200 order. Note that build-metadata is NOT used to calculated 4201 precedence. 4202 2. Precedence is determined by the first difference when 4203 comparing each of these identifiers, from left to right, 4204 as follows: 4205 a. Major, minor, and patch versions are always compared 4206 numerically (e.g., 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1) 4207 b. When major, minor, and patch are equal, a pre-release 4208 version has LOWER precedence than a normal version 4209 (e.g., 1.0.0-alpha < 1.0.0) 4210 c. Precedence for two pre-release versions with the same 4211 major, minor, and patch version MUST be determined by 4212 comparing each dot separated identifier from left to 4213 right until a difference is found as follows: 4214 - identifiers consisting only of digits are compared 4215 numerically and identifiers with letters and/or 4216 hyphens are compared lexically in ASCII sort order 4217 - Numeric identifiers always have lower precedence 4218 than non-numeric identifiers 4219 - A larger set of pre-release fields has a higher 4220 precedence than a smaller set, if all of the 4221 preceding identifiers are equal 4222 3. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha-beta 4223 < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0. 4225 Currently, the SUPAPolicyVersionMetadataDef class defines five 4226 attributes; these are described in the following subsections. 4228 5.20.1.1. The Attribute "supaVersionMajor" 4230 This is a mandatory string attribute, and contains a string 4231 representation of an integer that is greater than or equal to zero. 4232 It indicates that a significant increase in functionality is 4233 present in this version. It MAY also indicate that this version has 4234 changes that are NOT backwards-compatible; this MAY be denoted in 4235 the supaVersionBuildMetadata class attribute. 4237 The special string "0.1.0" is for initial development that MUST 4238 NOT be considered stable. Improvements to this initial version, 4239 before they are released to the public, are denoted by incrementing 4240 the minor and patch version numbers. 4242 The major version X (i.e., X.y.z, where X > 0) MUST be incremented 4243 if any backwards incompatible changes are introduced. It MAY 4244 include minor and patch level changes. The minor and patch version 4245 numbers MUST be reset to 0 when the major version number is 4246 incremented. 4248 5.20.1.2. The Attribute "supaVersionMinor" 4250 This is a mandatory string attribute, and contains a string 4251 representation of an integer that is greater than or equal to zero. 4252 It indicates that this release contains a set of features and/or 4253 bug fixes that MUST be backwards-compatible. 4255 The minor version Y (i.e., x.Y.z, where x > 0) MUST be incremented 4256 if new, backwards-compatible changes are introduced. It MUST be 4257 incremented if any features are marked as deprecated. It MAY be 4258 incremented if new functionality or improvements are introduced. 4259 It MAY include patch level changes. The patch version number MUST 4260 be reset to 0 when the minor version number is incremented. 4262 5.20.1.3. The Attribute "supaVersionPatch" 4264 This is a mandatory string attribute, and contains a string 4265 representation of an integer that is greater than or equal to zero. 4266 It indicates that this version contains ONLY bug fixes. 4268 The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented 4269 if new, backwards-compatible changes are introduced. A bug fix is 4270 defined as an internal change that fixes incorrect behavior. 4272 5.20.1.4. The Attribute "supaVersionPreRelease" 4274 This is an optional string attribute, and contains a string 4275 defining the pre-release version. 4277 A pre-release version MAY be denoted by appending a hyphen and a 4278 series of dot-separated identifiers immediately following the patch 4279 version. Identifiers MUST comprise only ASCII alphanumerics and a 4280 hyphen. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT 4281 include leading zeroes. Pre-release versions have a lower 4282 precedence than the associated normal version. A pre-release version 4283 indicates that the version is unstable and might not satisfy the 4284 intended compatibility requirements as denoted by its associated 4285 normal version. Examples include: 1.0.0-alpha, 4286 1.0.0-alpha.1, 1.0.0-0.3.7, and 1.0.0-x.7.z.92. 4288 5.20.1.5. The Attribute "supaVersionBuildMetadata" 4290 This is an optional string attribute, and contains a string defining 4291 the build metadata. Build metadata MAY be denoted by appending a 4292 plus sign and a series of dot-separated identifiers immediately 4293 following the patch or pre-release version. Identifiers MUST be 4294 made up of only ASCII alphanumerics and a hyphen. Identifiers 4295 MUST NOT be empty. Build metadata SHOULD be ignored when determining 4296 version precedence. Examples include: 1.0.0.-alpha+1, 4297 1.0.0+20130313144700, and 1.0.0-beta+exp.sha.5114f85. 4299 6. SUPA ECAPolicyRule Information Model 4301 This section defines the classes, attributes, and relationships 4302 of the SUPA ECAPolicyRule Information Model (EPRIM). Unless 4303 otherwise stated, all classes (and attributes) defined in this 4304 section were abstracted from DEN-ng [2], and a version of them are 4305 in the process of being added to [5]. 4307 6.1. Overview 4309 Conceptually, the EPRIM is a set of subclasses that specialize the 4310 concepts defined in the GPIM for representing the components of a 4311 Policy that uses ECA semantics. This is shown in Figure 23 (only 4312 new EPRIM subclasses and their GPIM superclasses are shown). 4314 (Class of another model that SUPA is integrating into) 4315 | 4316 +---SUPAPolicyObject (5.2) 4317 | 4318 +---SUPAPolicyStructure (5.3) 4319 | | 4320 | +---SUPAECAPolicyRule (6.4) 4321 | | 4322 | +---SUPAECAPolicyRuleAtomic (6.5) 4323 | | 4324 | +---SUPAECAPolicyRuleComposite (6.6) 4325 | 4326 +---SUPAPolicyComponentStructure (5.6) 4327 | 4328 +---SUPAPolicyClause (5.7) 4329 | | 4330 | +---SUPABooleanClause (6.7) 4331 | | 4332 | +---SUPAECAPolicyRuleAtomic (6.8) 4333 | | 4334 | +---SUPAECAPolicyRuleComposite (6.9) 4335 | 4336 +---SUPAPolicyComponentDecorator (5.9) 4337 | 4338 +---SUPAECAComponent(6.10) 4339 | 4340 +---SUPAPolicyEvent (6.11) 4341 | 4342 +---SUPAPolicyCondition (6.12) 4343 | 4344 +---SUPAPolicyAction (6.13) 4346 Figure 23. The EPRIM Class Hierarchy 4348 Specifically, the EPRIM specializes the SUPAPolicyStructure class 4349 class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it 4350 also specializes two subclasses of the SUPAPolicyComponentStructure 4351 class to create two new sets of policy components. These two 4352 SUPAPolicyComponentStructure subclasses are: 4354 o a new subclass of SUPAPolicyClause, called SUPABooleanClause 4355 (see sections 6.7 - 6.9), is defined for constructing Boolean 4356 clauses that are specific to the needs of ECA Policy Rules 4357 o a new subclass of SUPAPolicyComponentDecorator, called 4358 SUPAECAComponent (see sections 6.10 - 6.13), is defined for 4359 constructing reusable objects that represent Events, 4360 Conditions, and Actions 4362 The EPRIM provides new functionality, based on the GPIM, by 4363 extending the GPIM to define new classes and relationships. The 4364 EPRIM does NOT define new classes that are not inherited from 4365 existing GPIM classes. This ensures that the semantics of the GPIM 4366 are not changed, even though new functionality (for ECA Policy 4367 Rules and components) are being defined. 4369 The overall strategy for refining the GPIM is as follows: 4371 o SUPAECAPolicyRule is defined as a subclass of the GPIM 4372 SUPAPolicyStructure class 4373 o A SUPAECAPolicyRule has event, condition, and action clauses 4374 o Conceptually, this can be viewed as three aggregations 4375 between the SUPAECAPolicyRule and each clause 4376 o Each aggregation uses an instance of a concrete subclass of 4377 SUPAPolicyClause; this can be a SUPABooleanClause 4378 (making it ECA-specific), a SUPAEncodedClause (making it 4379 generic in nature), or a new subclass of SUPAPolicyClause 4380 o Concrete subclasses of SUPAPolicyClause may be decorated 4381 with zero or more concrete subclasses of the 4382 SUPAPolicyComponentDecorator class 4383 o An optional set of GPIM SUPAPolicySource objects can be 4384 defined to represent the authoring of a SUPAECAPolicyRule 4385 o An optional set of GPIM SUPAPolicyTarget objects can be 4386 defined to represent the set of managed entities that will be 4387 affected by this SUPAECAPolicyRule 4388 o An optional set of SUPAPolicyMetadata can be defined for any 4389 of the objects that make up a SUPAECAPolicyRule, including 4390 any of its components 4392 6.2. Constructing a SUPAECAPolicyRule 4394 There are several different ways to construct a SUPAECAPolicyRule; 4395 they differ in which set of components are used to define the 4396 content of the SUPAECAPolicyRule, and whether each component is 4397 decorated or not. The following are some examples of creating a 4398 SUPAECAPolicyRule: 4400 o Define three types of SUPABooleanClauses, one each for the 4401 event, condition, and action clauses that make up a 4402 SUPAECAPolicyRule 4403 o For one or more of the above clauses, associate an 4404 appropriate set of SUPAPolicyEvent, SUPAPolicyCondition, or 4405 SUPAPolicyAction objects, and complete the clause using an 4406 appropriate SUPAPolicyOperator and a corresponding 4407 SUPAPolicyValue or SUPAPolicyVariable 4408 o Note that compound Boolean clauses may be formed using 4409 one or more SUPABooleanClauseComposite objects with one or 4410 more SUPABooleanClauseAtomic objects 4412 o Define a SUPAPolicyCollection component, which is used to 4413 aggregate a set of objects appropriate for a clause, and 4414 complete the clause using an appropriate SUPAPolicyOperator 4415 and a corresponding SUPAPolicyValue or SUPAPolicyVariable 4416 o Create a new concrete subclass of SUPAPolicyComponentStructure 4417 (i.e., a sibling class of SUPAPolicyComponentDecorator and 4418 SUPAPolicyClause), and use this new subclass in a concrete 4419 subclass of SUPABooleanClause; note that this approach enables 4420 the new concrete subclass of SUPAPolicyComponentStructure to 4421 optionally be decorated as well 4422 o Create a new subclass of SUPAPolicyComponentDecorator (e.g., 4423 a sibling of SUPAECAComponent) that provides ECA-specific 4424 functionality, and use that to decorate a SUPAPolicyClause 4425 o Create a new concrete subclass of SUPAPolicyStructure that 4426 provides ECA-specific functionality, and define all or part 4427 of its content by aggregating a set of SUPAPolicyClauses 4429 6.3. Working With SUPAECAPolicyRules 4431 A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that 4432 MUST have three clauses, defined as follows: 4434 o The event clause defines a Boolean expression that, if TRUE, 4435 triggers the evaluation of its condition clause (if the 4436 event clause is not TRUE, then no further action for this 4437 policy rule takes place). 4438 o The condition clause defines a Boolean expression that, if 4439 TRUE, enables the actions in the action clause to be executed 4440 (if the condition clause is not TRUE, then no further action 4441 for this policy rule takes place). 4442 o The action clause contains a set of actions (note that an 4443 action MAY invoke another SUPAECAPolicyRule; see section 4444 6.13). 4446 Each of the above clauses can be a simple Boolean expression (of 4447 the form {variable operator value}, or a compound Boolean 4448 expression consisting of Boolean combinations of clauses. 4449 Compound Boolean expressions SHOULD be in CNF or DNF. 4451 Note that each of the above three clauses MAY have a set of 4452 SUPAPolicyMetadata objects that can constrain, or otherwise 4453 affect, how that clause is treated. For example, a set of 4454 SUPAPolicyMetadata MAY affect whether none, some, or all actions 4455 are executed, and what happens if an action fails. 4457 Each of the three clauses can be constructed from either a 4458 SUPAEncodedClause or a SUPABooleanClause. The advantage of using 4459 SUPAEncodedClauses is simplicity, as the content of the clause is 4460 encoded directly into the attributes of the SUPAEncodedClause. The 4461 advantage of using SUPABooleanClauses is reusability, since each 4462 term in each clause is potentially a reusable object. 4464 Since a SUPABooleanClause is a subclass of a SUPAPolicyClause 4465 (see Section 6.7), it can be decorated by one or more concrete 4466 subclasses of SUPAPolicyComponentDecorator. Therefore, a 4467 SUPAECAPolicyRule can be built entirely from objects defined in 4468 the GPIM and EPRIM, which facilitates the construction of 4469 SUPAPolicies by a machine. 4471 The relation between a SUPAECAPolicyRule and a SUPAPolicyClause 4472 is shown in Figure 24, and is explained in further detail in 4473 Section 6.4. 4475 SUPAHasPolicyClause 4476 +----------------+------------------------+ 4477 | ^ | 4478 | | | 4479 / \ | | 4480 A | | 4481 A \ / 0..1 | A 1..n \ / 4482 +----------+-----------+ | +-----------+------+ 4483 | SUPAPolicyStructure | | | SUPAPolicyClause | 4484 +----------+-----------+ | +-----------+------+ 4485 / \ | / \ 4486 I A | | 4487 I +----------+----------------+ | 4488 I | SUPAHasPolicyClauseDetail | | 4489 I +---------------------------+ | 4490 I | 4491 C I A | 4492 +----------+----------+ +--------+----------+ 4493 | SUPAECAPolicyRule | | SUPABooleanClause | 4494 +---------------------+ +-------------------+ 4496 Figure 24. SUPAECAPolicyRule Clauses 4498 The SUPAHasPolicyClause aggregation is implemented using the 4499 SUPAHasPolicyClauseDetail association class. These were 4500 described in sections 5.4.2.1 and 5.4.2.2, respectively. 4502 6.4. The Abstract Class "SUPAECAPolicyRule" 4504 This is a mandatory abstract class, which is a PolicyContainer 4505 that aggregates PolicyEvents, PolicyConditions, PolicyActions into 4506 a type of policy rule known as an Event-Condition-Action (ECA) 4507 policy rule. As previously explained, this has the following 4508 semantics: 4510 IF the event clause evaluates to TRUE 4511 IF the condition clause evaluates to TRUE 4512 THEN execute actions in the action clause 4513 ENDIF 4514 ENDIF 4516 The event clause, condition clause, and action clause collectively 4517 form a three-tuple. Each clause MUST be defined by at least one 4518 SUPAPolicyClause (which MAY be decorated with other elements, 4519 as described in section 5.7). 4521 Each of the three types of clauses is a 3-tuple of the form: 4523 {variable operator value} 4525 Each of the three clauses MAY be combined with additional clauses 4526 using any combination of logical AND, OR, and NOT operators; this 4527 forms a "compound" Boolean clause. For example, if A, B, and C are 4528 three attributes in an event, then a valid event clause could be: 4530 (A AND B) OR C 4532 Note that the above expression is in DNF; the equivalent CNF form 4533 is ((A OR C) AND (B OR C)). In either case, the output of all 4534 three clauses is either TRUE or FALSE; this facilitates combining 4535 and chaining SUPAECAPolicyRules. 4537 An action clause MAY invoke a new SUPAECAPolicyRule; see section 4538 6.13 for more details. 4540 An ECAPolicyRule MAY be optionally augmented with PolicySources 4541 and/or PolicyTargets (see sections 5.16 and 5.17, respectively). 4542 In addition, all objects that make up a SUPAECAPolicyRule MAY 4543 have SUPAPolicyMetadata (see section 5.16) attached to them to 4544 further describe and/or specify behavior. 4546 When defined in an information model, each of the event, condition, 4547 and action clauses MUST be represented as an aggregation between a 4548 SUPAECAPolicyRule (the aggregate) and a set of event, condition, 4549 or action objects (the components). However, a data model MAY map 4550 these definitions to a more efficient form (e.g., by flattening 4551 these three types of object instances, along with their respective 4552 aggregations, into a single object instance). 4554 The composite pattern [3] is applied to the SUPAECAPolicyRule 4555 class, enabling its (concrete) subclasses to be used as either a 4556 stand-alone policy rule or as a hierarchy of policy rules. 4557 SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both 4558 inherit from SUPAECAPolicyRule. This means that they are both 4559 a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule 4560 aggregation enables a particular SUPAECAPolicyRuleComposite 4561 object to aggregate both SUPAECAPolicyRuleComposite as well as 4562 SUPAECAPolicyRuleAtomic objects. In contrast, a 4563 SUPAECAPolicyRuleAtomic can NOT aggregate either a 4564 SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. 4565 SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are 4566 defined in sections 6.5 and 6.6, respectively. This is 4567 shown in Figure 25. 4569 A 4570 1..n +-------------------+ 4571 \| | 4572 +--------------- + SUPAECAPolicyRule | 4573 | /| | 4574 | +--------+----------+ 4575 | / \ 4576 | SUPAHasECAPolicyRule I 4577 | I 4578 | I 4579 | I 4580 | +---------------+-------------+ 4581 | I I 4582 / \ I I 4583 A I I 4584 C \ / 0..1 I C I 4585 +-----+---------+----------+ +-----------+-----------+ 4586 |SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic| 4587 +--------------------------+ +-----------------------+ 4589 Figure 25. The Composite Pattern Applied to a SUPAECAPolicyRule 4591 Note that the HasSUPAECAPolicyRule aggregation is defined by the 4592 HasSUPAECAPolicyRuleDetail association class; both are defined 4593 in sections 6.6.2 and 6.6.3, respectively. 4595 6.4.1. SUPAECAPolicyRule Attributes 4597 Currently, the SUPAECAPolicyRule defines two attributes, as 4598 described in the following subsections. 4600 6.4.1.1. The Attribute "supaECAPolicyRulePriority" 4602 This is a mandatory non-negative integer attribute that defines 4603 the priority of this particular SUPAECAPolicyRule. A larger value 4604 indicates a higher priority. A default value of 0 MAY be assigned. 4606 Priority is used primarily for 2 reasons: (1) to resolve conflicts 4607 among policy actions (e.g., given a set of conflicting actions, 4608 which one will execute) and (2) to define the execution order of 4609 policy actions (e.g., when one action may depend on the output of 4610 one or more previous actions). 4612 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" 4614 This is an optional non-negative enumerated integer whose value 4615 defines the current status of this policy rule. Values include: 4617 0: In development, not ready to be deployed 4618 1: Ready to be deployed 4619 2: Deployed but not enabled 4620 3: Deployed and enabled, but not executed 4621 4: Executed without errors 4622 5: Executed with errors 4623 6: Aborted during execution 4625 6.4.2. SUPAECAPolicyRule Relationships 4627 Currently, the SUPAECAPolicyRule does not define any 4628 relationships. It inherits all four relationships defined by 4629 the SUPAPolicyStructure class (see section 5.3.2.). 4631 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" 4633 This is a mandatory concrete class. This class is a type of 4634 PolicyContainer, and represents a SUPAECAPolicyRule that can 4635 operate as a single, stand-alone, manageable object. Put another 4636 way, a SUPAECAPolicyRuleAtomic object can NOT be modeled as a set 4637 of hierarchical SUPAECAPolicyRule objects; if this is required, 4638 then a SUPAECAPolicyRuleComposite object should be used instead. 4640 6.5.1. SUPAECAPolicyRuleAtomic Attributes 4642 Currently, the SUPAECAPolicyRuleAtomic class does not define any 4643 attributes. 4645 6.5.2. SUPAECAPolicyRuleAtomic Relationships 4647 Currently, the SUPAECAPolicyRuleAtomic class does not define any 4648 relationships. It inherits all four relationships defined by the 4649 SUPAPolicyStructure class (see section 5.3.2.). 4651 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" 4653 This is a mandatory concrete class. This class is a type of 4654 PolicyContainer, and represents a SUPAECAPolicyRule as a hierarchy 4655 of SUPAPolicy objects, where the hierarchy contains instances of a 4656 SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects. 4657 Each of the SUPAPolicy objects, including the outermost 4658 SUPAECAPolicyRuleComposite object, are separately manageable. More 4659 importantly, each SUPAECAPolicyRuleComposite object represents an 4660 aggregated object that is itself manageable. 4662 6.6.1. SUPAECAPolicyRuleComposite Attributes 4664 Currently, the SUPAECAPolicyRuleComposite defines one attribute, 4665 as described in the following subsection. 4667 6.6.1.1. The Attribute "supaECAEvalStrategy" 4669 This is a mandatory, non-zero, integer attribute that enumerates 4670 a set of allowable alternatives that define how the set of 4671 SUPAECAPolicyRule object instances in a SUPAECAPolicyRuleComposite 4672 object are evaluated. It is assumed that the event and condition 4673 clauses of the SUPAECAPolicyRules have evaluated to TRUE (e.g., the 4674 event has occurred and the conditions were met). Values include: 4676 0: undefined 4677 1: execute the first SUPAECAPolicyRule in the 4678 SUPAECAPolicyRuleComposite and then terminate 4679 2: execute only the highest priority SUPAECAPolicyRule(s) in 4680 the SUPAECAPolicyRuleComposite and then terminate 4681 3: execute all SUPAECAPolicyRules in prioritized order (if 4682 any) regardless of whether their SUPAPolicyActions 4683 succeed or fail 4684 4: execute all SUPAECAPolicyRules in prioritized order (if 4685 any) until at least one SUPAPolicyAction in a 4686 SUPAECAPolicyRule fails, and then terminate 4688 If the value of supaECAEvalStrategy is 3 or 4, then all 4689 SUPAECAPolicyRules that have a priority will be executed first 4690 (starting with the SUPAECAPolicyRule(s) that have the highest 4691 priority, and descending); all SUPAECAPolicyRule(s) that do not 4692 have a priority are then executed (in any order). 4694 Assume that the actions in a given SUPAECAPolicyRuleComposite 4695 are defined as follows 4697 SUPAECAPolicyRule A, priority 0 4698 SUPAECAPolicyRule B, priority 10 4699 SUPAECAPolicyRule C, priority 5 4700 SUPAECAPolicyRule D, priority 10 4701 SUPAECAPolicyRule E, priority 2 4703 Then, if the supaECAEvalStrategy attribute value equals: 4705 0: an error is issued 4706 1: only SUPAECAPolicyRule A is executed 4707 2: only SUPAECAPolicyRules B and D are executed 4708 3: all SUPAECAPolicyRules are executed, regardless of any 4709 failures in their SUPAPolicyActions 4710 4: all SUPAECAPolicyRules are executed until a failure is 4711 detected, and then execution for all SUPAECAPolicyRules 4712 terminate 4714 6.6.2. SUPAECAPolicyRuleComposite Relationships 4716 Currently, the SUPAECAPolicyRuleComposite defines a single 4717 aggregation between it and SUPAECAPolicyRule, as described below. 4719 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" 4721 This is an optional aggregation that implements the composite 4722 pattern. The multiplicity of this aggregation is 0..1 on the 4723 aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part 4724 (SUPAECAPolicyRule) side. This means that if this aggregation 4725 is defined, then at least one SUPAECAPolicyRule object (which may 4726 be either an instance of a SUPAECAPolicyRuleAtomic or a 4727 SUPAECAPolicyRuleComposite class) must also be instantiated and 4728 aggregated by this particular SUPAECAPolicyRuleComposite object. 4729 The semantics of this aggregation are defined by the 4730 SUPAHasECAPolicyRuleDetail association class. 4732 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" 4734 This is an optional concrete association class, and defines the 4735 semantics of the SUPHasECAPolicyRule aggregation. This enables the 4736 attributes and relationships of the SUPAHasECAPolicyRuleDetail 4737 class to be used to constrain which SUPHasECAPolicyRule objects 4738 can be aggregated by this particular SUPAECAPolicyRuleComposite 4739 object instance. 4741 6.6.3.1. The Attribute "supaECAPolicyIsDefault" 4743 This is an optional Boolean attribute. If the value of this 4744 attribute is true, then this SUPAECAPolicyRule is a default 4745 policy, and will be executed if no other SUPAECAPolicyRule 4746 in the SUPAECAPolicyRuleComposite container has been executed. 4747 This is a convenient way for error handling, though care should 4748 be taken to ensure that only one default policy rule is defined 4749 per SUPAECAPolicyRuleComposite container. 4751 6.7. The Abstract Class "SUPABooleanClause" 4753 A SUPABooleanClause specializes a SUPAPolicyClause, and defines 4754 a Boolean expression consisting of a standard structure in the 4755 form of a SUPAPolicyVariable, a SUPAPolicyOperator, and a 4756 SUPAPolicyValue. For example, this enables the following Boolean 4757 clause to be defined: 4759 Foo >= Baz 4761 where 'Foo' is a PolicyVariable, '>=' is a PolicyOperator, and 4762 'Baz' is a PolicyValue. 4764 Note that in this approach, the SUPAPolicyVariable and 4765 SUPAPolicyValue terms are defined as an appropriate subclass of 4766 the SUPAPolicyComponentDecorator class; it is assumed that the 4767 SUPAPolicyOperator is an instance of the SUPAPolicyOperator class. 4769 This enables the EPRIM, in conjunction with the GPIM, to be used 4770 as a reusable class library. This encourages interoperability, 4771 since each element of the clause is itself an object defined by 4772 the SUPA object hierarchy. 4774 An entire SUPABooleanClause may be negated by setting the 4775 supaBoolClauseIsNegated class attribute of the SUPABooleanClause 4776 class to TRUE. Individual terms of a Boolean clause can be negated 4777 by using the supaTermIsNegated Boolean attribute in the 4778 SUPAPolicyTerm class (see section 5.10). 4780 A PolicyClause is in Conjunctive Normal Form (CNF) if it is a 4781 sequence of logically ANDed terms, where each term is a sequence 4782 of logically ORed terms. 4784 A PolicyClause is in Disjunctive Normal Form (DNF) if it is a 4785 sequence of logically ORed terms, where each term is a sequence 4786 of logically ANDed terms. 4788 The construction of more complex clauses, which consist of a set 4789 of simple clauses in CNF or DNF (as shown in the above example), 4790 is provided by using the composite pattern [3] to construct two 4791 concrete subclasses of the abstract SUPABooleanClause class. These 4792 are called SUPABooleanClauseAtomic and SUPABooleanClauseComposite, 4793 and are defined in sections 6.8 and 6.9, respectively. This 4794 enables instances of either a SUPABooleanClauseAtomic and/or a 4795 SUPABooleanClauseComposite to be aggregated into a 4796 SUPABooleanClauseComposite object. 4798 6.7.1. SUPABooleanClause Attributes 4800 The SUPABooleanClause class currently defines one attribute, 4801 which are defined in the following subsections. 4803 6.7.1.1. The Attribute "supaBoolClauseIsNegated" 4805 This is a mandatory Boolean attribute. If the value of this 4806 attribute is TRUE, then this (entire) SUPABooleanClause is 4807 negated. Note that the supaPolTermIsNegated class attribute of 4808 the SUPAPolicyTerm class is used to negate a single term. 4810 6.7.2. SUPABooleanClause Relationships 4812 Currently, no relationships are defined for the SUPABooleanClause 4813 class. It inherits the relationships of SUPAPolicyClause (see 4814 section 5.5.). 4816 6.8. The Concrete Class "SUPABooleanClauseAtomic" 4818 This is a mandatory concrete class that represents a 4819 SUPABooleanClause that can operate as a single, stand-alone, 4820 manageable object. A SUPABooleanClauseAtomic object can NOT be 4821 modeled as a set of hierarchical clauses; if this functionality is 4822 required, then a SUPABooleanClauseComposite object must be used. 4823 Examples of Boolean clauses that could be contained in a 4824 SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P 4825 and Q are literals (e.g., a variable name that can be either true 4826 or false, or a formula that evaluates to a literal). Examples of 4827 Boolean clauses that are NOT in CNF are NOT(P AND Q), 4828 (P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent 4829 forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and 4830 P AND (Q OR S) AND (Q OR S), respectively. 4832 6.8.1. SUPABooleanClauseAtomic Attributes 4834 No attributes are currently defined for the 4835 SUPABooleanClauseAtomic class. 4837 6.8.2. SUPABooleanClauseAtomic Relationships 4839 Currently, no relationships are defined for the 4840 SUPABooleanClauseAtomic class. It inherits the relationships of 4841 SUPAPolicyClause (see section 5.5.). 4843 6.9. The Concrete Class "SUPABooleanClauseComposite" 4845 This is a mandatory concrete class that represents a 4846 SUPABooleanClause that can operate as a hierarchy of PolicyClause 4847 objects, where the hierarchy contains instances of 4848 SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite 4849 objects. Each of the SUPABooleanClauseAtomic and 4850 SUPABooleanClauseComposite objects, including the outermost 4851 SUPABooleanClauseComposite object, are separately manageable. 4853 More importantly, each SUPAECAPolicyRuleComposite object 4854 represents an aggregated object that is itself manageable. 4855 Examples of Boolean clauses that could be contained in a 4856 SUPABooleanClauseAtomic include ((P OR Q) AND R), and 4857 ((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, and 4858 T are literals. 4860 6.9.1. SUPABooleanClauseComposite Attributes 4862 Two attributes are currently defined for the 4863 SUPABooleanClauseComposite class, and are described in the 4864 following subsections. 4866 6.9.1.1. The Attribute "supaBoolClauseBindValue" 4868 This is a mandatory non-zero integer attribute, and defines the 4869 order in which terms bind to a clause. For example, the Boolean 4870 expression "((A AND B) OR (C AND NOT (D OR E)))" has the following 4871 binding order: terms A and B have a bind value of 1; term C has a 4872 binding value of 2, and terms D and E have a binding value of 3. 4874 6.9.1.2. The Attribute "supaBoolClauseIsCNF" 4876 This is an optional Boolean attribute. If the value of this 4877 attribute is TRUE, then this SUPABooleanClauseComposite is in CNF 4878 form. Otherwise, it is in DNF form. 4880 6.9.2. SUPABooleanClauseComposite Relationships 4882 Currently, the SUPABooleanClauseComposite class defined a single 4883 aggregation, which is described in the subsections below. 4885 6.9.2.1. The Aggregation "SUPAHasBooleanClause" 4887 This is a mandatory aggregation that defines the set of 4888 SUPABooleanClause objects that are aggregated by this 4889 SUPABooleanClauseComposite object. 4891 The multiplicity of this relationship is 0..1 on the aggregate 4892 (SUPABooleanClauseComposite) side, and 1..n on the part 4893 (SUPABooleanClause) side. This means that one or more 4894 SUPABooleanClauses are aggregated and used to define this 4895 SUPABooleanClauseComposite object. The 0..1 cardinality on the 4896 SUPABooleanClauseComposite side is necessary to enable 4897 SUPABooleanClauses to exist (e.g., in a PolicyRepository) before 4898 they are used by a SUPABooleanClauseComposite. The semantics of 4899 this aggregation is defined by the SUPAHasBooleanClauseDetail 4900 association class. 4902 6.9.3. The Association Class "SUPAHasBooleanClauseDetail" 4904 This is a mandatory concrete association class that defines the 4905 semantics of the SUPAHasBooleanClause aggregation. This enables the 4906 attributes and relationships of the SUPAHasBooleanClauseDetail 4907 class to be used to constrain which SUPABooleanClause objects 4908 can be aggregated by this particular SUPABooleanClauseComposite 4909 object instance. 4911 6.9.3.1. SUPAHasBooleanClauseDetail Attributes 4913 The SUPAHasBooleanClauseDetail class currently does not define 4914 any attributes. 4916 6.10. The Abstract Class "SUPAECAComponent" 4918 This is a mandatory abstract class that defines three concrete 4919 subclasses, one each to represent the concepts of reusable events, 4920 conditions, and actions. They are called SUPAPolicyEvent, 4921 SUPAPolicyCondition, and SUPAPolicyAction, respectively. 4923 SUPAECAComponents provide two different ways to construct 4924 SUPAPolicyClauses. The first is for the SUPAECAComponent to be 4925 used as either a SUPAPolicyVariable or a SUPAPolicyValue, and the 4926 second is for the SUPAECAComponent to contain the entire clause 4927 text. 4929 For example, suppose it is desired to define a policy condition 4930 clause with the text 'queueDepth > 10'. The two approaches could 4931 satisfy this as follows: 4933 Approach #1 (canonical form): 4934 SUPAPolicyCondition.supaPolicyConditionData contains the text 4935 'queueDepth' 4936 SUPAPolicyOperator.supaPolOpType is set to '1' (greater than) 4937 SUPAPolicyValue.supaPolValContent is set to '10' 4939 Approach #2 (SUPAECAComponent represents the entire clause): 4940 SUPAPolicyCondition.supaPolicyConditionData contains the text 4941 'queueDepth > 10' 4943 The class attribute supaECACompIsTerm, defined in subsection 4944 6.10.1.1, is used to identify which of these two approaches is 4945 used by an object instance of this class. 4947 6.10.1. SUPAECAComponent Attributes 4949 A single attribute is currently defined for this class, and is 4950 described in the following subsection. 4952 6.10.1.1. The Attribute supaECACompIsTerm 4954 This is an optional Boolean attribute. If the value of this 4955 attribute is TRUE, then this SUPAECAComponent is used as the value 4956 of a SUPAPolicyTerm to construct a SUPAPolicyClause (this is 4957 approach #1 in section 6.10 above). If the value of this attribute 4958 is FALSE, then this SUPAECAComponent contains the text of the 4959 entire corresponding SUPAPolicyClause (this is approach #2 in 4960 section 6.10 above). 4962 6.10.2. SUPAECAComponent Relationships 4964 No relationships are currently defined for this class. 4966 6.11. The Concrete Class "SUPAPolicyEvent" 4968 This is a mandatory concrete class that represents the concept of 4969 an Event that is applicable to a policy management system. Such 4970 an Event is defined as anything of importance to the management 4971 system (e.g., a change in the system being managed and/or its 4972 environment) occuring on a time-axis (as defined in [19]). 4973 SUPAPolicyEvents can be used as part of a SUPAPolicyClause; this 4974 is done by specifying the attribute name and value of an Event in 4975 the supaPolicyEventData attribute of the SUPAPolicyEvent. This 4976 enables event attributes to be used as part of a SUPAPolicyClause. 4978 Note: this class does NOT model the "raw" occurrences of Events. 4979 Rather, it represents the concept of an Event object whose class 4980 attributes describe pertinent attributes that can trigger the 4981 evaluation of a SUPAECAPolicyRule. 4983 6.11.1. SUPAPolicyEvent Attributes 4985 Currently, five attributes are defined for the SUPAPolicyEvent 4986 class, which are described in the following subsections. 4988 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 4990 This is an optional Boolean attribute. If the value of this 4991 attribute is TRUE, then this SUPAPolicyEvent has been pre- 4992 processed by an external entity, such as an Event Service Bus, 4993 before it was received by the Policy Management System. 4995 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" 4997 This is an optional Boolean attribute. If the value of this 4998 attribute is TRUE, then this SUPAPolicyEvent has been produced by 4999 the Policy Management System. If the value of this attribute is 5000 FALSE, then this SUPAPolicyEvent has been produced by an entity 5001 in the system being managed. 5003 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" 5005 This is a mandatory array of string attributes, and contains the 5006 subject that this PolicyEvent describes. 5007 Note: [0..n] means that this is a multi-valued property that has 5008 zero or more attributes. 5010 6.11.1.4. The Attribute "supaPolicyEventEncoding" 5012 This is a mandatory non-zero enumerated integer attribute, and 5013 defines how to interpret the supaPolicyEventData class attribute. 5014 These two attributes form a tuple, and together enable a machine 5015 to understand the syntax and value of the data carried by the 5016 object instance of this class. Values include: 5018 0: Undefined 5019 1: String 5020 2: Integer 5021 3: Boolean 5022 4: Floating Point 5023 5: DateTime 5025 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" 5027 This is a mandatory attribute that defines an array of strings. 5028 Each string in the array represents an attribute name and value 5029 of an Event object. The format of each string is defined as 5030 name:value. The 'name' part is the name of the SUPAPolicyEvent 5031 attribute, and the 'value' part is the value of that attribute. 5032 Note: [1..n] means that this is a multi-valued property that has 5033 at least one (and possibly more) attributes. For example, if 5034 this value of this attribute is: 5036 {(startTime:0800), (endTime:1700), (date:2016-05-11), 5037 (timeZone:-08:00)} 5039 then this attribute contains four properties, called startTime, 5040 endTime, date, and timeZone whose values are 0800, 1700, May 11 5041 2016, and Pacific Standard Time, respectively. 5043 Note that the supaPolicyEventEncoding class attribute defines how 5044 to interpret the value portion of this attribute. 5046 This attribute works with another class attribute, called 5047 supaPolicyEventEncoding, which defines how to interpret this 5048 attribute. These two attributes form a tuple, and together enable 5049 a machine to understand the syntax and value of the data carried 5050 by the object instance of this class. 5052 6.11.2. SUPAPolicyEvent Relationships 5054 No relationships are currently defined for this class. It inherits 5055 the relationships defined by the SUPAPolicyComponentDecorator (see 5056 section 5.7.3.). 5058 6.12. The Concrete Class "SUPAPolicyCondition" 5060 This is a mandatory concrete class that represents the concept of 5061 an Condition that will determine whether or not the set of Actions 5062 in the SUPAECAPolicyRule to which it belongs are executed or not. 5063 SUPAPolicyConditions can be used as part of a SUPAPolicyClause 5064 (e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or as a 5065 stand-alone SUPAPolicyClause (e.g., the supaPolicyConditionData 5066 attribute contains text that defines the entire condition clause). 5068 6.12.1. SUPAPolicyCondition Attributes 5070 Currently, two attributes are defined for the SUPAPolicyCondition 5071 class, which are described in the following subsections. 5073 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 5075 This is a mandatory array of string attributes that contains the 5076 content of this SUPAPolicyCondition object. 5077 Note: [1..n] means that this is a multi-valued property that has 5078 at least one (and possibly more) attributes. 5080 This attribute works with another class attribute, called 5081 supaPolicyConditionEncoding, which defines how to interpret this 5082 attribute. These two attributes form a tuple, and together enable 5083 a machine to understand the syntax and value of the data carried 5084 by the object instance of this class. 5086 6.12.1.2. The Attribute "supaPolicyConditionEncoding" 5088 This is a mandatory non-zero enumerated integer attribute, and 5089 defines the data type of the supaPolicyConditionData attribute. 5090 These two attributes form a tuple, and together enable a machine 5091 to understand the syntax and value of the content of this 5092 SUPAPolicyCondition object. Values include: 5094 0: undefined 5095 1: String 5096 2: OCL 2.x 5097 3: OCL 1.x 5098 4: QVT 1.2 - Relations Language 5099 5: QVT 1.2 - Operational language 5100 6: Alloy 5101 7: English text 5103 Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the 5104 latest version as of this writing). QVT defines a set of languages 5105 (the two most powerful and useful are defined by enumerations 4 5106 and 5). Alloy is a language for describing constraints, and uses a 5107 SAT solver to guarantee correctness. Note that enumeration 7 5108 (English text) is not recommended (since it is informal, and hence, 5109 not verifiable), but included for completeness. 5111 6.12.2. SUPAPolicyEvent Relationships 5113 No relationships are currently defined for this class. It inherits 5114 the relationships defined by the SUPAPolicyComponentDecorator (see 5115 section 5.7.3.). 5117 6.13. The Concrete Class "SUPAPolicyAction" 5119 This is a mandatory concrete class that represents the concept of 5120 an Action, which is a part of a SUPAECAPolicyRule, which may be 5121 executed when both the event and the condition clauses of its 5122 owning SUPAECAPolicyRule evaluate to true. The execution of this 5123 action is determined by its SUPAECAPolicyRule container, and any 5124 applicable SUPAPolicyMetadata objects. SUPAPolicyActions can be 5125 used in three different ways: 5127 o as part of a SUPAPolicyClause (e.g., var = 5128 SUPAPolicyAction.supaPolicyActionData) 5129 o as a stand-alone SUPAPolicyClause (e.g., the 5130 supaPolicyActionData attribute contains text that defines 5131 the entire action clause) 5132 o to invoke a SUPAECAPolicyRule 5134 In the third case, the execution semantics SHOULD be to suspend 5135 the current execution of the set of SUPAPolicyActions that are 5136 executing, transfer execution control to the invoked 5137 SUPAECAPolicyRule, and resume the execution of the original set 5138 of SUPAPolicyActions when the invoked SUPAECAPolicyRule has 5139 finished execution. 5141 6.13.1. SUPAPolicyAction Attributes 5143 Currently, two attributes are defined for the SUPAPolicyCondition 5144 class, which are described in the following subsections. 5146 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" 5148 This is a mandatory array of string attributes that contains the 5149 content of this SUPAPolicyAction object. This attribute works with 5150 another class attribute, called supaPolicyActionEncoding, which 5151 defines how to interpret this attribute. These two attributes form 5152 a tuple, and together enable a machine to understand the syntax 5153 and value of the data carried by the object instance of this class. 5154 Note: [1..n] means that this is a multi-valued property that has 5155 at least one (and possibly more) attributes. 5157 Since this attribute could represent a term in a SUPAPolicyClause 5158 (e.g., var = SUPAPolicyAction.supaPolicyActionData), a complete 5159 SUPAPolicyClause (e.g., the supaPolicyActionData attribute 5160 contains text that defines the entire action clause), or the 5161 name of a SUPAECAPolicyRule to invoke, each element in the string 5162 array is prepended with one of the following strings: 5164 o 't:' (or 'term:'), to denote a term in a SUPAPolicyClause 5165 o 'c:' (or 'clause:'), to denote an entire SUPAPolicyClause 5166 o 'r:' (or 'rule:'), to invoke a SUPAECAPolicyRule 5168 6.13.1.2. The Attribute "supaPolicyActionEncoding" 5170 This is a mandatory non-zero enumerated integer attribute, and 5171 defines the data type of the supaPolicyActionData attribute. This 5172 attribute works with another class attribute, called 5173 supaPolicyActionData, which contains the content of the action. 5174 These two attributes form a tuple, and together enable a machine 5175 to understand the syntax and value of the content of this 5176 SUPAPolicyAction object. Values include: 5178 0: undefined 5179 1: GUID 5180 2: UUID 5181 3: URI 5182 4: FQDN 5183 5: String 5184 6: OCL 2.x 5185 7: OCL 1.x 5186 8: QVT 1.2 - Relations Language 5187 9: QVT 1.2 - Operational language 5188 10: Alloy 5190 6.13.2. SUPAPolicyAction Relationships 5192 No relationships are currently defined for this class. It inherits 5193 the relationships defined by the SUPAPolicyComponentDecorator (see 5194 section 5.7.3.). 5196 Enumerations 1-4 are used to provide a reference to an action 5197 object. Enumerations 5-10 are used to express the action to 5198 perform as a string. 5200 7. Examples 5202 This will be defined in the next version of this document. 5204 8. Security Considerations 5206 This will be defined in the next version of this document. 5208 9. IANA Considerations 5210 This document has no actions for IANA. 5212 10. Contributors 5214 The following people contributed to creating this document, and are 5215 listed in alphabetical order: 5217 Jason Coleman 5219 11. Acknowledgments 5221 This document has benefited from reviews, suggestions, comments 5222 and proposed text provided by the following members, listed in 5223 alphabetical order: Andy Bierman, Bert Wijnen, Bob Natale, Dave 5224 Hood, Fred Feisullin, Georgios Karagiannis, Liu (Will) Shucheng, 5225 Marie-Jose Montpetit. 5227 12. References 5229 This section defines normative and informative references for this 5230 document. 5232 12.1. Normative References 5234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5235 Requirement Levels", BCP 14, RFC 2119, March 1997. 5237 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for 5238 the Network Configuration Protocol (NETCONF)", 5239 RFC 6020, October 2010. 5241 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 5242 July 2013. 5244 12.2. Informative References 5246 [RFC3060] Moore, B., Ellesson, E., Strassner, J., Westerinen, 5247 A., "Policy Core Information Model -- Version 1 5248 Specification", RFC 3060, February 2001 5250 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 5251 Scherling, M., Quinn, B., Herzog, S., Huynh, A., 5252 Carlson, M., Perry, J., Waldbusser, S., "Terminology 5253 for Policy-Based Management", RFC 3198, November, 2001 5255 [RFC3460] Moore, B., ed., "Policy Core Information Model (PCIM) 5256 Extensions, RFC 3460, January 2003 5258 [1] Strassner, J., "Policy-Based Network Management", 5259 Morgan Kaufman, ISBN 978-1558608597, Sep 2003 5261 [2] Strassner, J., ed., "The DEN-ng Information Model", 5262 add stable URI 5264 [3] Riehle, D., "Composite Design Patterns", Proceedings 5265 of the 1997 Conference on Object-Oriented Programming 5266 Systems, Languages and Applications (OOPSLA '97). 5267 ACM Press, 1997, Page 218-228 5269 [4] DMTF, CIM Schema, v2.44, 5270 http://dmtf.org/standards/cim/cim_schema_v2440 5272 [5] Strassner, J., ed., "ZOOM Policy Architecture and 5273 Information Model Snapshot", TR235, part of the 5274 TM Forum ZOOM project, October 26, 2014 5276 [6] TM Forum, "Information Framework (SID), GB922 and 5277 associated Addenda, v14.5, 5278 https://www.tmforum.org/information-framework-sid/ 5280 [7] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 5281 subtyping", ACM Transactions on Programming languages 5282 and Systems 16 (6): 1811 - 1841, 1994 5284 [8] Klyus, M., Strassner, J., Liu, W., Karagiannis, G., 5285 Bi, J., "SUPA Value Proposition", 5286 draft-klyus-supa-value-proposition-00, March 21, 2016 5288 [9] ISO/IEC 10746-3 (also ITU-T Rec X.903), "Reference 5289 Model Open Distributed Processing Architecture", 5290 April 20, 2010 5292 [10] Davy, S., Jennings, B., Strassner, J., "The Policy 5293 Continuum - A Formal Model", Proc. of the 2nd Intl. 5294 IEEE Workshop on Modeling Autonomic Communication 5295 Environments (MACE), Multicon Lecture Notes, No. 6, 5296 Multicon, Berlin, 2007, pages 65-78 5298 [11] Gamma, E., Helm, R., Johnson, R., Vlissides, J., 5299 "Design Patterns - Elements of Reusable Object-Oriented 5300 Software", Addison-Wesley, 1994, ISBN 0-201-63361-2 5302 [12] Strassner, J., de Souza, J.N., Raymer, D., Samudrala, 5303 S., Davy, S., Barrett, K., "The Design of a Novel 5304 Context-Aware Policy Model to Support Machine-Based 5305 Learning and Reasoning", Journal of Cluster Computing, 5306 Vol 12, Issue 1, pages 17-43, March, 2009 5308 [13] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 5309 subtyping", ACM Transactions on Programming languages 5310 and Systems, 16 (6): 1811 - 1841, 1994 5312 [14] Martin, R.C., "Agile Software Development, Principles, 5313 Patterns, and Practices", Prentice-Hall, 2002, 5314 ISBN: 0-13-597444-5 5316 [15] Halpern, J., Strassner, J., "Generic Policy Data Model 5317 for Simplified Use of Policy Abstractions (SUPA)" 5318 draft-ietf-supa-generic-policy-data-model-00, 5319 July 13, 2016 5321 [16] Wang, Y., Esposito, F., Matta, I., Day, J., "RINA: An 5322 Architecture for Policy-based Dynamic Service 5323 Management", Tech Report BUCS-TR-2013-014, 2013 5325 [17] Meyer, B., "Object-Oriented Software Construction", 5326 Prentice Hall, second edition, 1997 ISBN 0-13-629155-4 5328 [18] http://semver.org/ 5330 [19] ISO/IEC:2004(E), "Data elements and interchange 5331 formats -- Information interchange -- Representation 5332 of dates and times", 2004 5334 Authors' Addresses 5336 John Strassner 5337 Huawei Technologies 5338 2330 Central Expressway 5339 Santa Clara, CA 95138 USA 5340 Email: john.sc.strassner@huawei.com 5342 Joel Halpern 5343 Ericsson 5344 P. O. Box 6049 5345 Leesburg, VA 20178 5346 Email: joel.halpern@ericsson.com 5348 Sven van der Meer 5349 LM Ericsson Ltd. 5350 Ericsson Software Campus 5351 Garrycastle 5352 Athlone 5353 N37 PV44 5354 Ireland 5355 Email: sven.van.der.meer@ericsson.com 5357 Appendix A. Brief Analyses of Previous Policy Work 5359 This appendix describes of some of the important problems with 5360 previous IETF policy work., and describes the rationale for 5361 taking different design decisions in this document. 5363 A.1. PolicySetComponent vs. SUPAPolicyStructure 5365 The ability to define different types of policy rules is not 5366 present in [RFC3060] and [RFC3460], because both are based on [4], 5367 and this ability is not present in [4]. [RFC3060], [RFC3460], and 5368 [4] are all limited to CA (condition-action) policy rules. In 5369 addition, events are NOT defined. These limitations mean that 5370 RFC3060], [RFC3460], and [4] can only represent CA Policy Rules. 5372 In contrast, the original design goal of SUPA was to define a 5373 single class hierarchy that could represent different types of 5374 policies (e.g., imperative and declarative). Hence, it was 5375 decided to make SUPAPolicyStructure generic in nature, so that 5376 different types of policies could be defined as subclasses. This 5377 enables a single Policy Framework to support multiple types of 5378 policies. 5380 A.2. Flat Hierarchy vs. SUPAPolicyComponentStructure 5382 Figure 26 shows a portion of the class hierarchy of [RFC3460]. 5384 A 5385 +--------+ 5386 | Policy | 5387 +----+---+ 5388 / \ 5389 | 5390 | 5391 +---------+------+------+------------+-----------+ 5392 | | | | | 5393 A | | A | | A | 5394 +-----+-----+ | +--------+--------+ | +------+-------+ 5395 | PolicySet | | | PolicyCondition | | | PolicyAction | 5396 +-----+-----| | +--------+--------+ | +------+-------+ 5397 / \ | / \ | / \ 5398 | | | | | 5399 ... | ... | ... 5400 A | A | 5401 +-------+--------+ +-------+-----+ 5402 | PolicyVariable | | PolicyValue | 5403 +-------+--------+ +-------+-----+ 5404 / \ / \ 5405 | | 5406 ... ... 5408 Figure 26. Simplified Class Hierarcy of [RFC3460] 5410 RFC3060], [RFC3460], and [4] defined PolicyConditions and 5411 PolicyActions as subclasses of Policy (along with PolicySet, 5412 which is the superclass of PolicyRules and PolicyGroups). This 5413 means that there is no commonality between PolicyConditions and 5414 PolicyActions, even though they are both PolicyRule components. 5415 From an object-oriented point-of-view, this is incorrect, since a 5416 PolicyRule aggregates both PolicyConditions and PolicyActions. 5418 In addition, note that both PolicyVariables and PolicyValues are 5419 siblings of PolicyRules, PolicyConditions, and PolicyActions. This 5420 is incorrect for several reasons: 5422 o a PolicyRule cannot rectly contain PolicyVariables or 5423 PolicyValues, so they shouldn't be at the same level of the 5424 class hierarchy 5425 o both PolicyConditions and PolicyActions can contain 5426 PolicyVariables and PolicyValues, which implies that both 5427 PolicyVariables and PolicyValues should be lower in the 5428 class hierarchy 5430 Note that in the current version of [4], PolicyVariable and 5431 PolicyValue are both deleted. There are other changes as well, 5432 but they are beyond the scope of this Appendix. 5434 The original design goal of SUPA was to define a single class 5435 hierarchy that could represent different types of policies and 5436 policy components. This cannot be accomplished in [RFC3460], since 5437 there is no notion of a policy component (or alternatively, 5438 PolicyCondition, PolicyAction, PolicyVariable, and PolicyValue are 5439 all components at the same abstraction level, which is clearly not 5440 correct). Hence, SUPA defined the SUPAPolicyComponentStructure 5441 class to capture the concept of a reusable policy component. 5443 In summary, SUPAPolicyStructure subclasses define the structure of 5444 a policy in a common way, while SUPAPolicyComponentStructure 5445 subclasses define the content that is contained in the structure 5446 of a policy, also in a common way. 5448 A.3. PolicyRules and PolicyGroups vs. SUPAPolicyRules 5450 A PolicySetComponent is an aggregation, implemented as an 5451 association class, that "collects instances of PolicySet 5452 subclasses into coherent sets of Policies". This is a recursive 5453 aggregation, with multiplicity 0..n - 0..n, on the PolicySet 5454 class. 5456 Since this is a recursive aggregation, it means that a PolicySet 5457 can aggregate zero or more PolicySets. This is under-specified, 5458 and can be interpreted in one of two ways: 5460 1. A PolicySet subclass can aggregate any PolicySet subclass 5461 (PolicyRules can aggregate PolicyRules and PolicyGroups, and 5462 vice-versa) 5463 2. PolicyRules can aggregate PolicyRules, and PolicyGroups can 5464 aggregate PolicyGroups, but neither class can aggregate the 5465 other type of class 5467 Both interpretations are ill-suited for policy-based management. 5468 The problem with the first is that if PolicyGroup is the mechanism 5469 for grouping, why can a PolicyRule aggregate a PolicyGroup? This 5470 implies that PolicyGroups are not needed. The problem with the 5471 second is that PolicyGroups cannot aggregate PolicyRules (which 5472 again implies that PolicyGroups are not needed). 5474 Furthermore, there are no mechanisms defined in the [RFC3460] 5475 model to prevent loops of PolicyRules. This is a problem, because 5476 EVERY PolicyRule and PolicyGroup inherits this recursive 5477 aggregation. 5479 This is why this document uses the composite pattern. First, this 5480 pattern clearly shows what object is aggregating what other 5481 object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate a 5482 SUPAECAPolicyRuleComposite). Second, it does not allow a 5483 SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule 5484 (this is discussed more in the following subsection). 5486 A.3.1. Sub-rules 5488 Sub-rules (also called nested policy rules) enable a policy rule to 5489 be contained within another policy rule. These have very complex 5490 semantics, are very hard to debug, and provide limited value. They 5491 also require a complex set of aggregations (see section A.4.). 5493 The main reason for defining sub-rules in [RFC3460] is to enable 5494 "complex policy rules to be constructed from multiple simpler 5495 policy rules". However, the composite pattern does this much more 5496 efficiently than a simple recursive aggregation, and avoids the 5497 ambiguous semantics of a recursive aggregation. This latter point 5498 is important, because if PolicyRule and/or PolicyGroup is 5499 subclassed, then all subclasses still inherit this recursive 5500 aggregation, along with its ambiguous semantics. 5502 A.4. PolicyConditions and PolicyActions vs. SUPAECAComponent 5504 There is no need to use the SimplePolicyCondition and 5505 ComplexPolicyCondition objects defined in [RFC3460], since the 5506 SUPAPolicyComponentStructure uses the decorator pattern (see 5507 section 5.7) to provide more extensible types of conditions than is 5508 possible with those classes. This also applies for the 5509 SimplePolicyAction and the ComplexPolicyAction classes defined in 5510 [RFC3460]. 5512 More importantly, this removes the need for a complex set of 5513 aggregations (i.e., PolicyComponent, PolicySetComponent, 5514 PolicyConditionStructure, PolicyConditionInPolicyRule, 5515 PolicyConditionInPolicyCondition, PolicyActionStructure, 5516 PolicyActionInPolicyRule, and PolicyActionInPolicyAction). 5517 Instead, ANY SUPAECAComponent is defined as a decorator (i.e., a 5518 subclass of SUPAPolicyComponentDecorator), and hence, Any 5519 SUPAECAComponent is wrapped onto a concrete subclass of 5520 SUPAPolicyClause using the SAME aggregation 5521 (SUPAHasDecoratedPolicyComponent). This is a significantly simpler 5522 design that is also more powerful. 5524 A.5. The SUPAPolicyComponentDecorator Abstraction 5526 One of the problems in building a policy model is the tendency to 5527 have a multitude of classes, and hence object instances, to 5528 represent different combinations of policy events, conditions, and 5529 actions. This can lead to class and/or relationship explosion, as 5530 is the case in [RFC3460], [4], and [6]. 5532 For example, [RFC3460] defines five subclasses of PolicyCondition: 5533 PolicyTimePeriodCondition, VendorPolicyCondition, 5534 SimplePolicyCondition, CompoundPolicyCondition, and 5535 CompoundFilterCondition. Of these: 5537 o PolicyTimePeriodCondition is a data structure, not a class 5538 o VendorPolicyCondition represents a condition using two 5539 attributes that represent a multi-valued octet string 5540 o SimplePolicyCondition, CompoundPolicyCondition, and 5541 CompoundFilterCondition all have ambiguous semantics 5543 SimplePolicyCondition represents an ordered 3-tuple, in the form 5544 {variable, match, value}. However, the match operator is not 5545 formally modeled. Specifically, "the 'match' relationship is to 5546 be interpreted by analyzing the variable and value instances 5547 associated with the simple condition". This becomes problematic 5548 for several cases, such as shallow vs. deep object comparisons. 5549 More importantly, this requires two separate aggregations 5550 (PolicyVariableInSimplePolicyCondition and 5551 PolicyValueInSimplePolicyCondition) to associate variables and 5552 values to the SimplePolicyCondition, respectively. Since [RFC3460] 5553 defines all relationships as classes, this means that the 5554 expression "Foo > Bar" requires a total of FIVE objects (one each 5555 for the variable and value, one for the SimplePolicyCondition, and 5556 one each to associate the variable and value with the 5557 SimplePolicyCondition). 5559 This is exacerbated when SimplePolicyConditions are used to build 5560 CompoundPolicyConditions. In addition to the above complexity 5561 (which is required for each SimplePolicyCondition), a new 5562 aggregation (PolicyConditionInPolicyCondition) is required to 5563 aggregation PolicyConditions. Thus, the compound expression: 5564 "((Foo > Bar) AND (Foo < Baz))" requires a total of THIRTEEN 5565 objects (five for each of the terms being ANDed, plus one for the 5566 CompoundPolicyCondition, and two to aggregate each term to the 5567 CompoundPolicyCondition). 5569 Note that in the above examples, the superclasses of each of the 5570 relationships are omitted for clarity. In addition, [RFC3460] is 5571 built using inheritance; this means that if a new function is 5572 required, a new class must be built (e.g., CompoundFilterCondition 5573 is a subclass, but all it adds is one attribute). 5575 In constrast, the Decorator Pattern enables behavior to be 5576 selectively added to an individual object, either statically or 5577 dynamically, without having to build association classes. In 5578 addition, the decorator pattern uses composition, instead of 5579 inheritance, to avoid class explosion. This means that a new 5580 variable, value, or even condition class can be defined at 5581 runtime, and then all or part of that class can dynamically wrap 5582 an existing object without need for recompilation and 5583 redeployment. 5585 A.6. The Abstract Class "SUPAPolicyClause" 5587 This abstraction is missing in [RFC3060], [RFC3460], [4], and [6]. 5588 SUPAPolicyClause was abstracted from DEN-ng [2], and a version of 5589 this class is in the process of being added to [5]. However, the 5590 class and relationship design in [5] differs significantly from 5591 the corresponding designs in this document. 5593 SUPAPolicyClause further reinforces the different between a policy 5594 rule and a component of a policy rule by abstracting the content 5595 of a policy rule as a reusable object. This is fundamental for 5596 enabling different types of policy rules (e.g., imperative and 5597 declarative) to to be represented using the same constructs. 5599 A.7. Problems with the RFC3460 Version of PolicyVariable 5601 The following subsections define a brief, and incomplete, set of 5602 problems with the implementation of [RFC3460] (note that [RFC3060 5603 did not define variables, operators, and/or values). 5605 A.7.1. Object Bloat 5607 [RFC3460] used two different and complex mechanisms for providing 5608 generic get and set expressions. PolicyVariables were subclassed 5609 into two subclasses, even though they performed the same semantic 5610 function. This causes additional problems: 5612 o PolicyExplicitVariables are for CIM compatibility; note that 5613 the CIM does not contain either PolicyVariables or 5614 PolicyValues ([4]) 5615 o PolicyImplicitVariable subclasses do not define attributes; 5616 rather, they are bound to an appropriate subclass of 5617 PolicyValue using an association 5619 Hence, defining a variable is relatively expensive in [RFC3460], 5620 as in general, two objects and an association must be used. The 5621 objects themselves do not define content; rather, their names are 5622 used as a mechanism to identify an object to match. This means 5623 that an entire object must be used (instead of, for example, an 5624 attribute), which is wasteful. It also make it difficult to 5625 adjust constraints at runtime, since the constraint is defined in 5626 a class that is statically defined (and hence, requires 5627 recompilation and possibly redeployment if it is changed). 5629 A.7.2. Object Explosion 5631 The above three problems lead to class explosion (recall that in 5632 [RFC3060], [RFC3460], and [4], associations are implemented as 5633 classes). 5635 In contrast to this approach, the approach in this document keeps 5636 the idea of the class hierarchy for backwards compatibility, but 5637 streamlines the implementation. Specifically: 5639 1. The decorator pattern is an established and very used 5640 software pattern (it dates back to at least 1994 [11]). 5641 2. The use of a single association class 5642 (i.e., SUPAHasDecoratedPolicyComponentDetail) can represent 5643 more constraints than is possible in the approaches of 5644 [RFC3460] and [4] in a much more flexible manner, due to its 5645 function as a decorator of other objects. 5646 3. Note that there is no way to enforce the constraint matching 5647 in [RFC3460] and [6]; the burden is on the developer to 5648 check and see if the constraints specified in one class are 5649 honored in the other class. 5650 4. If these constraints are not honored, there is no mechanism 5651 specified to define the clause as incorrectly formed. 5653 A.7.3. Specification Ambiguities 5655 There are a number of ambiguities in [RFC3460]. 5657 First, [RFC3460] says: "Variables are used for building individual 5658 conditions". While this is true, variables can also be used for 5659 building individual actions. This is reflected in the definition 5660 for SUPAPolicyVariable. 5662 Second, [RFC3460] says: "The variable specifies the property of a 5663 flow or an event that should be matched when evaluating the 5664 condition." While this is true, variables can be used to test many 5665 other things than "just" a flow or an event. This is reflected in 5666 the SUPAPolicyVariable definition. 5668 Third, the [RFC3460] definition requires the use of associations 5669 in order to properly constrain the variable (e.g., define its 5670 data type, the range of its allowed values, etc.). This is both 5671 costly and inefficient. 5673 Fourth, [RFC3460] is tightly bound to the DMTF CIM schema [4]. 5674 The CIM is a data model (despite its name), because: 5676 o It uses keys and weak relationships, which are both concepts 5677 from relational algebra and thus, not technology-independent 5678 o It has its own proprietary modeling language 5679 o It contains a number of concepts that are not defined in UML 5680 (including overriding keys for subclasses) 5682 Fifth, the class hierarchy has two needless classes, called 5683 SUPAImplicitVariable and SUPAExplicitVariable. These classes do 5684 not define any attributes or relationships, and hence, do not 5685 add any semantics to the model. 5687 Finally, in [RFC3460], defining constraints for a variable is 5688 limited to associating the variable with a PolicyValue. This is 5689 both cumbersome (because associations are costly; for example, 5690 they equate to a join in a relational database management system), 5691 and not scalable, because it is prone to proliferating PolicyValue 5692 classes for every constraint (or range of constraints) that is 5693 possible. Therefore, in SUPA, this mechanism is replaced with 5694 using an association to an association class that defines 5695 constraints in a much more general and powerful manner (i.e., 5696 the SUPAHasDecoratedPolicyComponentDetail class). 5698 A.8. Problems with the RFC3460 Version of PolicyValue 5700 The following subsections define a brief, and incomplete, set of 5701 problems with the implementation of [RFC3460] (note that [RFC3060 5702 did not define variables, operators, and/or values). 5704 A.8.1. Object Bloat 5706 [RFC3460] defined a set of 7 subclasses; three were specific to 5707 networking (i.e., IPv4 Address, IPv6 Address, MAC Address) and 4 5708 (PolicyStringValue, PolicyBitStringValue, PolicyIntegerValue, and 5709 PolicyBooleanValue) were generic in nature. However, each of these 5710 objects defined a single class attribute. This has the same two 5711 problems as with PolicyVariables (see section 5.9.1.1): 5713 1. Using an entire object to define a single attribute is very 5714 wasteful and expensive 5715 2. It also make it difficult to adjust constraints at runtime, 5716 since the constraint is defined in a class that is statically 5717 defined (and hence, requires recompilation and possibly 5718 redeployment if it is changed). 5720 A.8.2. Object Explosion 5722 [RFC3460] definition requires the use of associations 5723 in order to properly constrain the variable (e.g., define its 5724 data type, the range of its allowed values, etc.). This is both 5725 costly and inefficient (recall that in [RFC3060], [RFC3460], and 5726 [4], associations are implemented as classes). 5728 A.8.3. Lack of Constraints 5730 There is no generic facility for defining constraints for a 5731 PolicyValue. Therefore, there is no facility for being able to 5732 change such constraints dynamically at runtime. 5734 A.8.4. Tightly Bound to the CIM Schema 5736 [RFC3460] is tightly bound to the DMTF CIM schema [4]. The CIM is 5737 a data model (despite its name), because: 5739 o It uses keys and weak relationships, which are both concepts 5740 from relational algebra and thus, not technology-independent 5741 o It has its own proprietary modeling language 5742 o It contains a number of concepts that are not defined in UML 5743 (including overriding keys for subclasses) 5745 A.8.5. Specification Ambiguity 5747 [RFC3460] says: It is used for defining values and constants used 5748 in policy conditions". While this is true, variables can also be 5749 used for building individual actions. This is reflected in the 5750 SUPAPolicyVariable definition. 5752 A.8.6. Lack of Symmetry 5754 Most good information models show symmetry between like components. 5755 [RFC3460] has no symmetry in how it defines variables and values. 5756 In contrast, this document recognizes that variables and values 5757 are just terms in a clause; hence, the only difference in the 5758 definition of the SUPAPolicyVariable and SUPAPolicyValue classes 5759 is that the content attribute in the former is a single string, 5760 whereas the content attribute in the latter is a string array. 5761 In particular, the semantics of both variables and values are 5762 defined using the decorator pattern, along with the attributes of 5763 the SUPAPolicyComponentDecorator and the 5764 SUPAHasDecoratedPolicyComponentDetail classes.