idnits 2.17.00 (12 Aug 2021) /tmp/idnits61303/draft-ietf-supa-generic-policy-info-model-03.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 3 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 (May 30, 2017) is 1810 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) == Outdated reference: A later version (-04) exists of draft-ietf-supa-generic-policy-data-model-03 Summary: 0 errors (**), 0 flaws (~~), 3 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: November 30, 2017 S. van der Meer 5 Ericsson 6 May 30, 2017 8 Generic Policy Information Model for 9 Simplified Use of Policy Abstractions (SUPA) 10 draft-ietf-supa-generic-policy-info-model-03 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 November 30, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided 50 without warranty as described in the Simplified BSD License. 52 Table of Contents 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 96 4.2.1. Design Patterns ..................................... 23 97 4.2.1.1. Composite Pattern .............................. 24 98 4.2.1.2. Decorator Pattern .............................. 24 99 4.2.2. Association Classes ................................. 26 101 Table of Contents (continued) 103 4.3. SUPA Generic Policy Information Model Overview............ 27 104 4.3.1. SUPAPolicyObject .................................... 29 105 4.3.2. SUPAPolicyStructure ................................. 30 106 4.3.3. SUPAPolicyComponentStructure ........................ 30 107 4.3.4. SUPAPolicyClause .................................... 31 108 4.3.5. SUPAPolicyClauseComponentDecorator .................. 31 109 4.3.6. SUPAPolicyTarget .................................... 32 110 4.3.7. SUPAPolicySource .................................... 32 111 4.4. The Design of the GPIM ................................... 32 112 4.4.1. Structure of Policies ............................... 33 113 4.4.2. Representing an ECA Policy Rule ..................... 34 114 4.4.3. Creating SUPA Policy Clauses ........................ 37 115 4.4.4. Creating SUPAPolicyClauses .......................... 41 116 4.4.5. SUPAPolicySources ................................... 42 117 4.4.6. SUPAPolicyTargets ................................... 43 118 4.4.7. SUPAPolicyMetadata .................................. 43 119 4.4.7.1. Motivation ..................................... 44 120 4.4.7.2. Design Approach ................................ 45 121 4.4.7.2.1. Policies and Actors ....................... 46 122 4.4.7.2.2. Deployment vs. Execution of Policies ...... 47 123 4.4.7.2.3. Using SUPAMetadata for Policy Deployment 124 and Execution ............................. 47 125 4.4.7.3. Structure of SUPAPolicyMetadata ................ 48 126 5. GPIM Model .................................................... 52 127 5.1. Overview ................................................. 52 128 5.2. The Abstract Class "SUPAPolicyObject" .................... 53 129 5.2.1. SUPAPolicyObject Attributes ......................... 54 130 5.2.1.1. Object Identifiers ............................. 54 131 5.2.1.2. The Attribute "supaPolObjIDContent" ............ 55 132 5.2.1.3. The Attribute "supaPolObjIDEncoding" ........... 55 133 5.2.1.4. The Attribute "supaPolicyDescription" .......... 55 134 5.2.1.5. The Attribute "supaPolicyName" ................. 55 135 5.2.2. SUPAPolicy Relationships ............................ 56 136 5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 56 137 5.2.2.2. The Association Class 138 "SUPAHasPolicyMetadataDetail" .................. 56 139 5.3. The Abstract Class "SUPAPolicyStructure" ................. 56 140 5.3.1. SUPAPolicyStructure Attributes ...................... 57 141 5.3.1.1. The Attribute "supaPolAdminStatus" ............. 57 142 5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 57 143 5.3.1.3. The Attribute "supaPolDeployStatus" ............ 58 144 5.3.1.4. The Attribute "supaPolExecFailStrategy" ........ 58 145 5.3.2. SUPAPolicyStructure Relationships ................... 59 146 5.3.2.1. The Aggregation "SUPAHasPolicySource" .......... 59 147 5.3.2.2. The Association Class 148 "SUPAHasPolicySourceDetail" .................... 59 149 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" . 59 150 5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" ....... 59 152 Table of Contents (continued) 154 5.3.2.3. The Aggregation "SUPAHasPolicyTarget" .......... 59 155 5.3.2.4. The Association Class 156 "SUPAHasPolicyTargetDetail" ................... 60 157 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" . 60 158 5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" ....... 60 159 5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" . 60 160 5.3.2.6. The Association Class 161 "SUPAHasPolExecFailTakeActionDetail" ........... 61 162 5.3.2.6.1. The Attribute 163 "supaPolExecFailActionEncoding" ........... 61 164 5.3.2.6.2. The Attribute 165 "supaPolExecFailActionName[1..n]" ......... 62 166 5.3.2.7. The Aggregation "SUPAHasPolicyClause" .......... 62 167 5.3.2.8. The Association Class 168 "SUPAHasPolicyClauseDetail" .................... 63 169 5.4. The Abstract Class "SUPAPolicyComponentStructure" ........ 63 170 5.4.1. SUPAPolicyComponentStructure Attributes ............. 63 171 5.4.2. SUPAPolicyComponentStructure Relationships .......... 63 172 5.5. The Abstract Class "SUPAPolicyClause" .................... 64 173 5.5.1. SUPAPolicyClause Attributes ......................... 65 174 5.5.1.1. The Attribute "supaPolClauseDeployStatus" ...... 65 175 5.5.2. SUPAPolicyClause Relationships ...................... 65 176 5.5.2.1. The Aggregation "SUPAPolicyClauseHasDecorator" . 66 177 5.5.2.2. The Association Class 178 "SUPAPolicyClauseHasDecoratorDetail" ........... 66 179 5.5.2.2.1. The Attribute 180 "supaPolClauseDecConstraintEncoding" ...... 66 181 5.5.2.2.2. The Attribute 182 "supaPolClauseDecConstraint[0..n]" ........ 66 183 5.6. The Concrete Class "SUPAEncodedClause" ................... 67 184 5.6.1. SUPAEncodedClause Attributes ........................ 67 185 5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 68 186 5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 68 187 5.6.1.3. The Attribute "supaEncodedClauseLanguage" ...... 68 188 5.6.1.4. The Attribute "supaEncodedClauseResponse" ...... 69 189 5.6.2. SUPAEncodedClause Relationships ..................... 69 190 5.7. The Abstract Class "SUPAPolicyClauseComponentDecorator ... 69 191 5.7.1. SUPAPolicyClauseComponentDecorator Attributes ....... 70 192 5.7.1.1. The Attribute "supaPolClauseConstraintEncoding" 70 193 5.7.1.2. The Attribute "supaPolClauseConstraint[0..n]" .. 71 194 5.7.2. SUPAPolicyClauseComponentDecorator Relationships .... 71 195 5.7.3. Illustration of Constraints in the Decorator Pattern 71 196 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 72 197 5.8.1. SUPAPolicyTerm Attributes ........................... 73 198 5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 73 199 5.8.2. SUPAPolicyTerm Relationships ........................ 73 201 Table of Contents (continued) 203 5.9. The Concrete Class "SUPAPolicyVariable" .................. 74 204 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 74 205 5.9.2. SUPAPolicyVariable Attributes ....................... 74 206 5.9.2.1. The Attribute "supaPolVarName" ................. 74 207 5.9.3. SUPAPolicyVariable Relationships .................... 75 208 5.10. The Concrete Class "SUPAPolicyOperator" ................. 75 209 5.10.1. Problems with the RFC3460 Version .................. 75 210 5.10.2. SUPAPolicyOperator Attributes ...................... 75 211 5.10.2.1. The Attribute "supaPolOpType" ................. 75 212 5.10.3. SUPAPolicyOperator Relationships ................... 76 213 5.11. The Concrete Class "SUPAPolicyValue" .................... 76 214 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 77 215 5.11.2. SUPAPolicyValue Attributes ......................... 77 216 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 77 217 5.11.2.2. The Attribute "supaPolValEncoding" ............ 77 218 5.11.3. SUPAPolicyValue Relationships ...................... 78 219 5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 78 220 5.12.1. SUPAGenericDecoratedComponent Attributes ........... 78 221 5.12.1.1. The Attribute 222 "supaGenericDecoratedCompContent[0..n]" ....... 79 223 5.12.1.2. The Attribute 224 "supaGenericDecoratedCompEncoding" ............ 79 225 5.12.2. SUPAGenericDecoratedComponent Relationships ........ 79 226 5.13. The Concrete Class "SUPAPolicyCollection" ............... 80 227 5.13.1. Motivation ......................................... 80 228 5.13.2. Solution ........................................... 80 229 5.13.3. SUPAPolicyCollection Attributes .................... 81 230 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 81 231 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 81 232 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 81 233 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 82 234 5.13.3.5. The Attribute "supaPolCollectionType" ......... 82 235 5.13.4. SUPAPolicyCollection Relationships ................. 83 236 5.14. The Abstract Class "SUPAPolicyComponentDecorator ........ 83 237 5.14.1. SUPAPolicyComponentDecorator Attributes ............ 84 238 5.14.1.1. The Attribute "supaPolCompConstraintEncoding" . 84 239 5.14.1.2. The Attribute "supaPolCompConstraint[0..n]" ... 85 240 5.14.2. SUPAPolicyComponentDecorator Relationships ......... 85 241 5.14.2.1. The Aggregation 242 "SUPAHasDecoratedPolicyComponent" ............. 85 243 5.14.2.2. The Association Class 244 "SUPAHasDecoratedPolicyComponentDetail" ....... 85 245 5.14.2.1.1. The Attribute 246 "supaPolCompConstraintEncoding" .......... 86 247 5.14.2.1.2. The Attribute 248 "supaPolCompConstraint[0..n]" ............ 86 250 Table of Contents (continued) 252 5.15. The Concrete Class "SUPAPolicySource" .................... 86 253 5.15.1. SUPAPolicySource Attributes ........................ 86 254 5.15.2. SUPAPolicySource Relationships ..................... 87 255 5.16. The Concrete Class "SUPAPolicyTarget" ................... 87 256 5.16.1. SUPAPolicyTarget Attributes ........................ 87 257 5.16.2. SUPAPolicyTarget Relationships ..................... 87 258 5.17. The Abstract Class "SUPAPolicyMetadata" ................. 88 259 5.17.1. SUPAPolicyMetadata Attributes ...................... 89 260 5.17.1.1. The Attribute "supaPolMetadataDescription" .... 89 261 5.17.1.2. The Attribute "supaPolMetadataIDContent" ...... 89 262 5.17.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 89 263 5.17.1.4. The Attribute "supaPolMetadataName" ........... 90 264 5.17.2. SUPAPolicyMetadata Relationships ................... 90 265 5.17.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 90 266 5.17.2.2. The Association Class 267 "SUPAHasPolicyMetadataDetail" ................. 90 268 5.17.2.2.1. The Attribute 269 "supaPolMetadataConstraintEncoding" ...... 90 270 5.17.2.2.2. The Attribute 271 "supaPolMetadataConstraint[0..n]" ........ 91 272 5.17.2.2.3. The Attribute 273 "supaPolMetadataIsApplicable" ............ 91 274 5.18. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 91 275 5.18.1. SUPAPolicyConcreteMetadata Attributes .............. 91 276 5.18.1.1. The Attribute "supaPolMDValidPeriodEnd" ...... 92 277 5.18.1.2. The Attribute "supaPolMDValidPeriodStart" .... 92 278 5.18.2. SUPAPolicyConcreteMetadata Relationships ........... 92 279 5.19. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 92 280 5.19.1. SUPAPolicyMetadataDecorator Attributes ............. 92 281 5.19.2. SUPAPolicyMetadataDecorator Relationships .......... 92 282 5.19.2.1. The Aggregation "SUPAHasMetadataDecorator" .... 92 283 5.19.2.2. The Association Class 284 "SUPAHasMetadataDecoratorDetail" .............. 93 285 5.19.2.2.1. The Attribute 286 "supaPolMetadataConstraintEncoding" ...... 93 287 5.19.2.2.2. The Attribute 288 "supaPolMetadataConstraint[0..n]" ........ 94 289 5.19.2.2.3. The Attribute 290 "supaPolMetadataDecIsApplicable" ......... 94 291 5.20. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 94 292 5.20.1. SUPAPolicyAccessMetadataDef Attributes ............. 94 293 5.20.1.1. The Attribute "supaPolAccessPrivilegeDef" ..... 94 294 5.20.1.2. The Attribute "supaPolAccessPrivilegeModelName" 95 295 5.20.1.3. The Attribute "supaPolAccessPrivilegeModelRef" 95 297 Table of Contents (continued) 299 5.21. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 96 300 5.21.1. SUPAPolicyVersionMetadataDef Attributes ............ 96 301 5.21.1.1. The Attribute "supaVersionMajor" .............. 97 302 5.21.1.2. The Attribute "supaVersionMinor" .............. 98 303 5.21.1.3. The Attribute "supaVersionPatch" .............. 98 304 5.21.1.4. The Attribute "supaVersionPreRelease" ......... 98 305 5.21.1.5. The Attribute "supaVersionBuildMetadata" ...... 98 306 6. SUPA ECAPolicyRule Information Model .......................... 99 307 6.1. Overview ................................................. 99 308 6.2. Constructing a SUPAECAPolicyRule ........................ 101 309 6.3. Working With SUPAECAPolicyRules ......................... 101 310 6.4. The Abstract Class "SUPAECAPolicyRule" .................. 103 311 6.4.1. SUPAECAPolicyRule Attributes ....................... 105 312 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ..... 105 313 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ....... 105 314 6.4.2. SUPAECAPolicyRule Relationships .................... 105 315 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............ 105 316 6.5.1. SUPAECAPolicyRuleAtomic Attributes ................. 106 317 6.5.1.1. The Attribute "supaECAPolActionEvalStrategy" .. 106 318 6.5.2. SUPAECAPolicyRuleAtomic Relationships .............. 107 319 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" ......... 107 320 6.6.1. SUPAECAPolicyRuleComposite Attributes .............. 108 321 6.6.1.1. The Attribute "supaECAEvalRuleStrategy" ....... 108 322 6.6.2. SUPAECAPolicyRuleComposite Relationships ........... 110 323 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ........ 110 324 6.6.2.2. The Association Class 325 "SUPAHasECAPolicyRuleDetail" .................. 109 326 6.6.2.2.1. The Attribute "supaECAPolicyIsDefault" ... 109 327 6.7. The Abstract Class "SUPABooleanClause" .................. 109 328 6.7.1. SUPABooleanClause Attributes ....................... 110 329 6.7.1.1. The Attribute "supaBoolClauseBindValue" ....... 110 330 6.7.1.2. The Attribute "supaBoolClauseIsCNF" ........... 110 331 6.7.1.3. The Attribute "supaBoolClauseIsNegated" ....... 111 332 6.7.2. SUPABooleanClause Relationships .................... 111 333 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............ 111 334 6.8.1. SUPABooleanClauseAtomic Attributes ................. 111 335 6.8.2. SUPABooleanClauseAtomic Relationships .............. 111 336 6.9. The Concrete Class "SUPABooleanClauseComposite" ......... 111 337 6.9.1. SUPABooleanClauseComposite Attributes .............. 112 338 6.9.2. SUPABooleanClauseComposite Relationships ........... 112 339 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ........ 112 340 6.9.2.2. The Association Class 341 "SUPAHasBooleanClauseDetail" .................. 112 342 6.9.2.2.1. The Attribute "supaIsHornClause" ............ 112 343 6.10. The Abstract Class "SUPAECAComponent" .................. 113 344 6.10.1. SUPAECAComponent Attributes ....................... 113 345 6.10.1.1. The Attribute "supaECACompIsTerm" ............ 113 346 6.10.2. SUPAECAComponent Relationships .................... 113 348 Table of Contents (continued) 350 6.11. The Concrete Class "SUPAPolicyEvent" ................... 114 351 6.11.1. SUPAPolicyEvent Attributes ........................ 114 352 6.11.1.1. The Attribute "supaPolicyEventData[1..n]" .... 114 353 6.11.1.2. The Attribute "supaPolicyEventEncoding[1..n]" 115 354 6.11.1.3. The Attribute "supaPolicyEventIsPreProcessed" 115 355 6.11.1.4. The Attribute "supaPolicyEventIsSynthetic" ... 115 356 6.11.1.5. The Attribute "supaPolicyEventTopic[0..n]" ... 116 357 6.11.2. SUPAPolicyEvent Relationships ..................... 116 358 6.12. The Concrete Class "SUPAPolicyCondition" ............... 116 359 6.12.1. SUPAPolicyCondition Attributes .................... 116 360 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 116 361 6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 117 362 6.12.2. SUPAPolicyCondition Relationships ................. 117 363 6.13. The Concrete Class "SUPAPolicyAction" .................. 117 364 6.13.1. Restrictions about SUPAPolicyActions Calling 365 SUPAPolicies ...................................... 118 366 6.13.2. SUPAPolicyAction Attributes ....................... 119 367 6.13.2.1. The Attribute "supaPolicyActionData[1..n]" ... 119 368 6.13.2.2. The Attribute "supaPolicyActionEncoding" ..... 119 369 6.13.3. SUPAPolicyAction Relationships .................... 120 370 7. Examples ..................................................... 121 371 7.1. Example 1: Blocking SNMP Traffic ....................... 121 372 7.1.1. Introduction ....................................... 121 373 7.1.2. Solution Approach .................................. 121 374 7.1.3. Solution for Case 1 (SUPAPolicies Control 375 Behavior) ....................................... 122 376 7.1.3.1. Strategy ................................... 123 377 7.1.3.2. Implementation ............................. 124 378 7.1.4. Solution for Case 2 (SUPAPolicies Do Not 379 Control Behavior) .................................. 127 380 7.1.4.1. Approach ...................................... 127 381 7.1.4.2. Implementation ............................. 128 382 8. Security Considerations ..................................... 130 383 9. IANA Considerations .......................................... 130 384 10. Contributors ................................................ 130 385 11. Acknowledgments ............................................. 130 386 12. References .................................................. 130 387 12.1. Normative References ................................... 130 388 12.2. Informative References ................................ 131 389 Authors' Addresses ............................................... 133 390 Appendix A. Brief Analyses of Previous Policy Work .............. 134 391 1. Overview 393 This document defines an information model for representing 394 policies using a common extensible framework that is independent 395 of language, protocol, repository, and the level of abstraction of 396 the content and meaning of a policy. This enables a common set of 397 concepts defined in this information model to be mapped into 398 different representations of policy (e.g., procedural, imperative, 399 and declarative). It also enables different data models that use 400 different languages, protocols, and repositories to optimize 401 their usage. The definition of common policy concepts also 402 provides better interoperability by ensuring that each data 403 model can share a set of common concepts, independent of its 404 level of detail or the language, protocol, and/or repository 405 that it is using. It is also independent of the target data 406 model that will be generated. 408 This version of the information model focuses on defining one 409 type of policy rule: the event-condition-action (ECA) policy rule. 410 Accordingly, this document defines two sets of model elements: 412 1. A framework for defining the concept of policy, 413 independent of how policy is represented or used; this is 414 called the SUPA Generic Policy Information Model (GPIM) 415 2. A framework for defining a policy model that uses the 416 event-condition-action (ECA) paradigm; this is called the 417 SUPA ECA Policy Rule Information Model (EPRIM), and extends 418 concepts from the GPIM. 420 The combination of the GPIM and the EPRIM provides an extensible 421 framework for defining policy that uses an event-condition-action 422 representation that is independent of data repository, data 423 definition language, query language, implementation language, and 424 protocol. 426 The Appendix provides a brief analysis of previous work in the 427 field of policy modeling. 429 1.1. Introduction 431 Simplified Use of Policy Abstractions (SUPA) defines a technology- 432 independent neutral information model for creating high-level, 433 possibly network-wide policies as input and producing element 434 configurations (either whole or snippets) as output. SUPA addresses 435 the needs of operators, end-users, and application developers to 436 represent multiple types of ECA policy rules, such as for traffic 437 selection and configuration or security. These ECA policy rules may 438 vary in the level of abstraction to suit the needs of different 439 actors (e.g., end-users vs. administrators) [1], [10]. 441 Different constituencies of users would like to use terminology and 442 concepts that are familiar to each constituency. Rather than require 443 multiple software systems to be used for each constituency, a common 444 information model enables these different concepts and terms to be 445 mapped to elements in the information model. This facilitiates the 446 use of a single software system to generate data models for each 447 language. In the example shown in Figure 1 (which is a simplified 448 Policy Continuum [10]), each constituency uses different concepts 449 and terms (according to their skill sets and roles) to formulate 450 (ECA) policy rules that are useful for their job functions. A 451 unified information model is one way to build a consensual lexicon 452 that enables terms from one language to be mapped to terms of 453 another language. This approach enables the syntax of each language 454 to be modified appropriate to its user while keeping a common set 455 of semantics for all languages. This is shown in Figure 1. 457 +-------------------+ 458 | Information Model | 459 | and one or more +<------------------------+ 460 | Data Models | | 461 +-------------------+ | 462 | 463 +---------------------+ | 464 +---------------+ \| High-level Policies | \+-------------+ | 465 | Business User |----| Without Technical |----| Language #1 +<----+ 466 +---------------+ /| Terminology | /+-------------+ | 467 +---------------------+ | 468 | 469 +---------------------+ | 470 +---------------+ \| Policies That Use | \+-------------+ | 471 | Developer |----| Classes, Attributes,|----| Language #2 +<----+ 472 +---------------+ /| Relationships, ... | /+-------------+ | 473 +---------------------+ | 474 | 475 ... ... ... | 476 | 477 +---------------------+ | 478 +---------------+ \| Low-level Policies | \+-------------+ | 479 | Admin |----| with Technology- |----| Language #n +<----+ 480 +---------------+ /| Specific Terms in a | /+-------------+ 481 | Specific Language | 482 +---------------------+ 484 Figure 1. Different Constituencies Need Different Policies 486 More importantly, an information model defines concepts in a 487 uniform way, enabling formal mapping processes to be developed to 488 translate the information model to a set of data models. This 489 simplifies the process of constructing software to automate the 490 policy management process. It also simplifies the language 491 generation process, though that is beyond the scope of this 492 document. 494 This common framework takes the form of an information model that 495 is divided into one high-level module and one or more number of 496 lower-level modules. A lower-level module extends the higher-level 497 module into a new domain; each lower-level domain module can itself 498 be extended to model more granular domain-specific (but still 499 technology- and vendor-independent) concepts as necessary. 501 Conceptually, a set of model elements (e.g., classes, attributes, 502 constraints, and relationships) are used to define the Generic 503 Policy Information Model (GPIM); this module defines a common set of 504 policy concepts that are independent of the type of policy (e.g., 505 imperative, procedural, declarative, or otherwise). Then, any number 506 of additional modules can be derived from the GPIM; each additional 507 module MUST extend the GPIM to define a new type of policy rule by 508 adding to the GPIM. Each additoinal module MUST NOT alter any of 509 the model elements of the GPIM. The use of extensions preserves the 510 interoperability of this approach; if the base GPIM was modified, 511 then this would adversely compromise interoperability. 513 The SUPA ECA Policy Rule Information Model (EPRIM) extends the 514 GPIM to represent policy rules that use the Event-Condition-Action 515 (ECA) paradigm. 517 1.2. Changes Since Version -02 519 There are several changes in this version of this document 520 compared to the previous versions of this document. They are: 522 1) Fixed ASCII art in several figures 523 2) Added enumerations to supaPolOpType to sync with I2NSF 524 3) Fixed supaVendorDecoratedCompEncoding 525 4) Corrected attribute definitions in supaPolicyCollection 526 5) Corrected attribute definition of supaPolMetadataIDEncoding 527 6) Added Figures 2 and 3; renumbered subsequent Figures 528 7) Enhanced supaPolicyEventEncoding definition 529 8) Added supaECAPolActionEcalStrategy to SUPAPolicyRuleComposite 530 9) Added section 6.13.1. 531 10) Added new section about design patterns (4.2.1) 532 11) Added new section describing how association classes are 533 used (4.2.2) 534 12) ECA stuff 535 13) revised decorator pattern 536 14) Fixed typos 538 2. Conventions Used in This Document 540 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 541 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 542 this document are to be interpreted as described in [RFC2119]. In 543 this document, these words will appear with that interpretation 544 only when in ALL CAPS. Lower case uses of these words are not to 545 be interpreted as carrying [RFC2119] significance. 547 3. Terminology 549 This section defines acronyms, terms, and symbology used in the 550 rest of this document. 552 3.1. Acronyms 554 CLI Command Line Interface 555 CRUD Create, Read, Update, Delete 556 CNF Conjunctive Normal Form 557 DNF Disjunctive Normal Form 558 ECA Event-Condition-Action 559 EPRIM (SUPA) ECA Policy Rule Information Model 560 GPIM (SUPA) Generic Policy Information Model 561 OAM&P Operations, Administration, Management, and Provisioning 562 OID Object IDentifier 563 SAT Satisfiability, short for Boolean Satisfiability Problem 564 SUPA Simplified Use of Policy Abstractions 565 TMF TeleManagent Forum (TM Forum) 566 UML Unified Modeling Language 567 URI Uniform Resource Identifier 568 YANG A data definition language for use with NETCONF 569 ZOOM Zero-touch Orchestration, Operations, and Management 570 (a TMF project that also works on information models) 572 3.2. Definitions 574 This section defines the terminology that is used in this document. 576 3.2.1. Core Terminology 578 The following subsections define the terms "information model" and 579 "data model", as well as "container" and "policy container". 581 3.2.1.1. Information Model 583 An information model is a representation of concepts of interest 584 to an environment in a form that is independent of data repository, 585 data definition language, query language, implementation language, 586 and protocol. 588 Note: this definition is more specific than that of [RFC3198], so 589 as to focus on the properties of information models. That definition 590 was: "An abstraction and representation of the entities in a managed 591 environment, their properties, attributes and operations, and the 592 way that they relate to each other. It is independent of any 593 specific repository, software usage, protocol, or platform." 595 3.2.1.2. Data Model 597 A data model is a representation of concepts of interest to an 598 environment in a form that is dependent on data repository, data 599 definition language, query language, implementation language, and/or 600 protocol (typically, but not necessarily, all five). 602 Note: this definition is more specific than that of [RFC3198], so 603 as to focus on the properties of data models that are generated 604 from information models. That definition was: "A mapping of the 605 contents of an information model into a form that is specific to a 606 particular type of data store or repository." 608 3.2.1.3. Class 610 A class is a set of objects that exhibit a common set of 611 characteristics and behavior. 613 3.2.1.3.1. Abstract Class 615 An abstract class is a class that cannot be directly instantiated. 616 It MAY have abstract or concrete subclasses. It is denoted with a 617 capital A (for abstract) near the top-left side of the class. 619 3.2.1.3.2. Concrete Class 621 A concrete class is a class that can be directly instantiated. Note 622 that classes are either abstract or concrete. In addition, once a 623 class has been defined as concrete in the hierarchy, all of its 624 subclasses MUST also be concrete. It is denoted with a capital C 625 (for concrete) near the top-left side of the class. 627 3.2.1.4. Container 629 A container is an object whose instances may contain zero or more 630 additional objects, including container objects. A container 631 provides storage, query, and retrieval of its contained objects 632 in a well-known, organized way. 634 3.2.1.5. PolicyContainer 636 In this document, a PolicyContainer is a special type of container 637 that provides at least the following three functions: 639 1. It uses metadata to define how its content is interpreted 640 2. It separates the content of the policy from the 641 representation of the policy 642 3. It provides a convenient control point for OAM&P operations 644 The combination of these three functions enables a PolicyContainer 645 to define the behavior of how its constituent components will be 646 accessed, queried, stored, retrieved, and how they operate. 648 This document does NOT define a specific data type to implement 649 a PolicyContainer, as many different types of data types can be 650 used. However, the data type chosen SHOULD NOT allow duplicate 651 members in the PolicyContainer. In addition, order is irrelevant, 652 since priority will override any initial order of the members of 653 this PolicyContainer. 655 3.2.2. Policy Terminology 657 The following terms define different policy concepts used in the 658 SUPA Generic Policy Information Model (GPIM). Note that the 659 prefix "SUPA" is used for all classes and relationships defined 660 in this model to ensure name uniqueness. Similarly, the prefix 661 "supa" is defined for all SUPA class attributes. 663 3.2.2.1. SUPAPolicyObject 665 A SUPAPolicyObject is the root of the GPIM class hierarchy. It is 666 an abstract class that all classes inherit from, except the 667 SUPAPolicyMetadata class and its subclasses. 669 3.2.2.2. SUPAPolicy 671 A SUPAPolicy is, in this version of this document, an ECA policy 672 rule that is a type of PolicyContainer. The PolicyContainer MUST 673 contain a SUPAECAPolicyRule, SHOULD contain one or more 674 SUPAPolicyMetadata objects, and MAY contain other elements that 675 define the semantics of the policy rule. Policies are generically 676 defined as a means to monitor and control the changing and/or 677 maintaining of the state of one or more managed objects [1]. In 678 this context, "manage" means that one or more of the following six 679 fundamental operations are supported: create, read, write, delete, 680 start, and stop) [16]. 682 3.2.2.3. SUPAPolicyClause 684 A SUPAPolicyClause is an abstract class. Its subclasses define 685 different types of clauses that are used to create the content 686 for different types of SUPAPolicies. 688 For example, the SUPABooleanClause subclass models the content 689 of a SUPAPolicy as a Boolean clause, where each Boolean clause 690 is made up of a set of reusable objects. In contrast, a 691 SUPAEncodedClause encodes the entire clause as a set of 692 attributes. All types of SUPAPolicies MUST use one or more 693 SUPAPolicyClauses to construct a SUPAPolicy. 695 3.2.2.4. SUPAECAPolicyRule 697 An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an 698 abstract class that is a type of PolicyContainer. It represents 699 a policy rule as a three-tuple, consisting of an event, a 700 condition, and an action clause. In an information model, this 701 takes the form of three different aggregations, one for each 702 clause. Each clause MUST be represented by at least one 703 SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain 704 zero or more SUPAPolicySources, zero or more SUPAPolicyTargets, 705 and zero or more SUPAPolicyMetadata objects. Note that for this 706 version of this document, ECA Policy Rules are the **only** 707 types of Policies that are defined. 709 3.2.2.5. SUPAMetadata 711 Metadata is, literally, data about data. SUPAMetadata is an 712 abstract class that contains prescriptive and/or descriptive 713 information about the object(s) to which it is attached. While 714 metadata can be attached to any information model element, this 715 document only considers metadata attached to classes and 716 relationships. 718 When defined in an information model, each instance of the 719 SUPAMetadata class MUST have its own aggregation relationship 720 with the set of objects that it applies to. However, a data model 721 MAY map these definitions to a more efficient form (e.g., 722 flattening the object instances into a single object instance). 724 3.2.2.6. SUPAPolicyTarget 726 SUPAPolicyTarget is an abstract class that defines a set of 727 managed objects that may be affected by the actions of a 728 SUPAPolicyClause. A SUPAPolicyTarget may use one or more 729 mechanisms to identify the set of managed objects that it 730 affects; examples include OIDs and URIs. 732 When defined in an information model, each instance of the 733 SUPAPolicyTarget class MUST have its own aggregation 734 relationship with each SUPAPolicy that uses it. However, a 735 data model MAY map these definitions to a more efficient form 736 (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and 737 SUPAPolicy object instances into a single object instance). 739 3.2.2.7. SUPAPolicySource 741 SUPAPolicySource is an abstract class that defines a set of 742 managed objects that authored this SUPAPolicyClause. This is 743 required for auditability and authorization policies, as well 744 as some forms of deontic and alethic logic. 746 A SUPAPolicySource may use one or more mechanisms to identify the 747 set of managed objects that authored it; examples include OIDs and 748 URIs. Specifically, policy CRUD MUST be subject to authentication 749 and authorization, and MUST be auditable. Note that the mechanisms 750 for doing these three operations are currently not included, and 751 are for further discussion. 753 When defined in an information model, each instance of the 754 SUPAPolicySource class MUST have its own aggregation relationship 755 with each SUPAPolicy that uses it. However, a data model MAY map 756 these definitions to a more efficient form (e.g., flattening the 757 SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances 758 into a single object instance). 760 3.2.3. Modeling Terminology 762 The following terms define different types of relationships used 763 in the information models of the SUPA Generic Policy Information 764 Model (GPIM). 766 3.2.3.1. Inheritance 768 Inheritance makes an entity at a lower level of abstraction (e.g., 769 the subclass) a type of an entity at a higher level of abstraction 770 (e.g., the superclass). Any attributes and relationships that are 771 defined for the superclass are also defined for the subclass. 772 However, a subclass does NOT change the characteristics or behavior 773 of the attributes or relationships of the superclass that it 774 inherits from. Formally, this is called the Liskov Substitution 775 Principle [7]. This principle is one of the key characteristics 776 that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. 778 A subclass MAY add new attributes and relationships that refine 779 the characteristics and/or behavior of it compared to its 780 superclass. A subclass MUST NOT change inherited attributes or 781 relationships. 783 3.2.3.2. Relationship 785 A relationship is a generic term that represents how a first set 786 of entities interact with a second set of entities. A recursive 787 relationship sets the first and second entity to the same entity. 788 There are three basic types of relationships, as defined in the 789 subsections below: associations, aggregations, and compositions. 791 A subclass MUST NOT change the multiplicity (see section 3.2.3.7) 792 of a relationship that it inherits. A subclass MUST NOT change any 793 attributes of a relation that it inherits that is realized using 794 an association class (see section 3.2.3.6). 796 3.2.3.3. Association 798 An association represents a generic dependency between a first 799 and a second set of entities. In an information model, an 800 association MAY be represented as a class. 802 3.2.3.4. Aggregation 804 An aggregation is a stronger type (i.e., more restricted 805 semantically) of association, and represents a whole-part 806 dependency between a first and a second set of entities. Three 807 objects are defined by an aggregation: the first entity, the 808 second entity, and a new third entity that represents the 809 combination of the first and second entities. 811 The entity owning the aggregation is referred to as the 812 "aggregate", and the entity that is aggregated is referred to as 813 the "part". In an information model, an aggregation MAY be 814 represented as a class. 816 3.2.3.5. Composition 818 A composition is a stronger type (i.e., more restricted 819 semantically) of aggregation, and represents a whole-part 820 dependency with two important behaviors. First, an instance of the 821 part is included in at most one instance of the aggregate at a 822 time. Second, any action performed on the composite entity (i.e., 823 the aggregate) is propagated to its constituent part objects. 824 For example, if the composite entity is deleted, then all of its 825 constituent part entities are also deleted. This is not true of 826 aggregations or associations - in both, only the entity being 827 deleted is actually removed, and the other entities are unaffected. 828 In an information model, a composition MAY be represented as 829 a class. 831 3.2.3.6. Association Class 833 A relationship may be implemented as an association class. This is 834 used to define the relationship as having its own set of features. 835 (Note: in this document, all relationships are implemented as 836 association classes for consistency and to simplify implementation.) 837 More specifically, if the relationship is implemented as an 838 association class, then the attributes of the association class, as 839 well as other relationships that the association class participates 840 in, may be used to define the semantics of the relationship. If the 841 relationship is not implemented as an association class, then no 842 additional semantics (beyond those defined by the type of the 843 relationship) are expressed by the relationship. 845 3.2.3.7. Multiplicity 847 A specification of the range of allowable cardinalities that a set 848 of entities may assume. This is always a pair of ranges, such as 849 1 - 1 or 0..n - 2..5. 851 3.2.3.8. Navigability 853 A relationship may restrict one object from accessing the other 854 object. This document defines two choices: 856 1. Each object is navigable by the other, which is indicated 857 by NOT providing any additional symbology, or 858 2. An object A can navigate to object B, but object B cannot 859 navigate to object A. This is indicated by an open-headed 860 arrow pointing to the object that cannot navigate to the 861 other object. An example is shown below: 863 +---------+ 3..4 +---------+ 864 | | 1..2 \| | 865 | Class A |--------------| Class B | 866 | | /| | 867 +---------+ +---------+ 869 The above figure shows a navigability restriction. Class A can 870 navigate to Class B, but Class B cannot navigate to Class A. This is 871 a mandatory association, since none of the multiplicities contain a 872 '0'. This association reads as follows: 874 Class A depends on 3 to 4 instances of Class B, and 875 Class B depends on 1 to 2 instances of Class A. 877 3.3. Symbology 879 The following symbology is used in this document. 881 3.3.1. Inheritance 883 Inheritance: a subclass inherits the attributes and relationships 884 of its superclass, as shown below: 886 +------------+ 887 | Superclass | 888 +------+-----+ 889 / \ 890 I 891 I 892 I 893 +------+-----+ 894 | Subclass | 895 +------------+ 897 3.3.2. Association 899 Association: Class B depends on Class A, as shown below: 901 +---------+ +---------+ 902 +---------+ +---------+ | | \| | 903 | Class A |------| Class B | | Class A |------| Class B | 904 +---------+ +---------+ | | /| | 905 +---------+ +---------+ 907 association with no association with 908 navigability restrictions navigability restrictions 910 3.3.3. Aggregation 912 Aggregation: Class B is the part, Class A is the aggregate, 913 as shown below: 915 +---------+ +---------+ +---------+ 916 | |/ \ +---------+ | |/ \ \| | 917 | Class A | A ---| Class B | | Class A | A ------| Class B | 918 | |\ / +---------+ | |\ / /| | 919 +---------+ +---------+ +---------+ 921 aggregation with no aggregation with 922 navigability restrictions navigability restrictions 924 3.3.4. Composition 926 Composition: Class B is the part, Class A is the composite, 927 as shown below: 929 +---------+ +---------+ +---------+ 930 | |/ \ +---------+ | |/ \ \| | 931 | Class A | C ---| Class B | | Class A | C ------| Class B | 932 | |\ / +---------+ | |\ / /| | 933 +---------+ +---------+ +---------+ 935 composition with no composition with 936 navigability restrictions navigability restrictions 938 3.3.5. Association Class 940 Association Class: Class C is the association class implementing 941 the relationship D between classes A and B 942 +---------+ +---------+ 943 | Class A |----+-----| Class B | 944 +---------+ ^ +---------+ 945 | 946 | 947 +----------+----------+ 948 | Association Class C | 949 +---------------------+ 951 3.3.6. Abstract vs. Concrete Classes 953 In UML, abstract classes are denoted with their name in italics. 954 For this draft, a capital 'A' will be placed at either the top 955 left or right corner of the class to signify that the class is 956 abstract. Similarly, a captial 'C' will be placed in the same 957 location to represent a concrete class. This is shown below. 959 A C 960 +---------+ +---------+ 961 | Class A | | Class B | 962 +---------+ +---------+ 964 An Abstract Class A Concrete Class 966 4. Policy Abstraction Architecture 968 This section describes the policy abstractions that are used in 969 SUPA. The following abstractions are provided: 971 o The GPIM defines a technology-neutral information model that 972 can express the concept of Policy. 973 o All classes, except for SUPAPolicyMetadata, inherit from 974 SUPAPolicyObject, or one of its subclasses. 975 o SUPAPolicyObject and SUPAPolicyMetadata are designed to 976 inherit from classes in another model; the GPIM does not 977 define an "all-encompassing" model. 978 o This version of this document restricts the expression of 979 Policy to a set of event-condition-action clauses. 980 o Each clause is defined as a Boolean expression, and MAY 981 also be defined as a reusable object. 982 o Clauses may be combined to form more complex Boolean 983 expressions. 984 o The purpose of the GPIM is to enable different policies that 985 have fundamentally different representations to share common 986 model elements. Policy statements, which are implemented as 987 instances of the SUPAPolicyClause class, separate the content 988 of a Policy from its representation. This is supported by: 989 o All policy rules (of which SUPAECAPolicyRule is the 990 first example of a concrete class) are derived from 991 the SUPAPolicyStructure class. 992 o All objects that are components of policy rules are 993 derived from the SUPAPolicyComponentStructure class. 994 o A SUPAPolicy MUST contain at least one SUPAPolicyClause. 995 o A SUPAPolicy MAY specify one or more SUPAPolicyTarget, 996 SUPAPolicySource, and SUPAPolicyMetadata objects to 997 augment the semantics of the SUPAPolicy 998 o A SUPAPolicyClause has two subclasses: 999 o A SUPABooleanClause, which is used to build 1000 SUPAECAPolicyRules from reusable objects. 1001 o A SUPAEncodedClause, which is used for using attributes 1002 instead of objects to construct a SUPAECAPolicyRule. 1003 o A SUPAECAPolicyRule defines the set of events and conditions 1004 that are responsible for executing its actions; it MUST have 1005 at least one event clause, at least one condition clause, and 1006 at least one action clause. 1007 o The action(s) of a SUPAECAPolicyRule are ONLY executed 1008 if both the event and condition clauses evaluate to TRUE 1009 o A SUPAPolicyAction MAY invoke another SUPAPolicyAction in 1010 another SUPAECAPolicyRule (see section 6.13). 1011 o SUPAMetadata MAY be defined for any SUPAPolicyObject class. 1012 o SUPAMetadata MAY be prescriptive and/or descriptive in nature. 1014 This model, and its abstractions, define an interoperable 1015 representation of policies that can be communicated between 1016 different actors. Generation and execution of these policies 1017 is beyond the scope of this document. 1019 4.1. Motivation 1021 The power of policy management is its applicability to many 1022 different types of systems. There are many different actors that 1023 can use a policy management system, including end-users, operators, 1024 application developers, and administrators. Each of these 1025 constituencies have different concepts and skills, and use 1026 different terminology. For example, an operator may want to express 1027 an operational rule that states that only Platinum and Gold users 1028 can use streaming multimedia applications. As a second example, a 1029 network administrator may want to define a more concrete policy 1030 rule that looks at the number of dropped packets and, if that 1031 number exceeds a programmable threshold, changes the queuing and 1032 dropping algorithms used. 1034 SUPA may be used to define other types of policies, such as for 1035 systems and operations management; an example is: "All routers and 1036 switches must have password login disabled". See section 3 of [8] 1037 for additional declarative and ECA policy examples. 1039 All of the above examples are commonly referred to as "policy 1040 rules", but they take very different forms, since they are at very 1041 different levels of abstraction and typically authored by 1042 different actors. The first was very abstract, and did not contain 1043 any technology-specific terms, while the second was more concrete, 1044 and likely used technical terms of a general (e.g., IP address 1045 range, port numbers) as well as a vendor-specific nature (e.g., 1046 specific queuing, dropping, and/or scheduling algorithms 1047 implemented in a particular device). The third restricted the type 1048 of login that was permissible for certain types of devices in the 1049 environment. 1051 Note that the first two policy rules could directly affect each 1052 other. For example, Gold and Platinum users might need different 1053 device configurations to give the proper QoS markings to their 1054 streaming multimedia traffic. This is very difficult to do if a 1055 common policy model does not exist, especially if the two policies 1056 are authored by different actors that use different terminology 1057 and have different skill sets. More importantly, the users of 1058 these two policies likely have different job responsibilities. 1059 They may have no idea of the concepts used in each policy. Yet, 1060 their policies need to interact in order for the business to 1061 provide the desired service. This again underscores the need for 1062 a common policy framework. 1064 Certain types of policy rules (e.g., ECA) may express actions, or 1065 other types of operations, that contradict each other. SUPA 1066 provides a rich object model that can be used to support language 1067 definitions that can find and resolve such problems. 1069 Models built using this IM are intended primarily for communicating 1070 policy, not for executing policy. 1072 4.2. SUPA Approach 1074 The purpose of the SUPA Generic Policy Information Model (GPIM) is 1075 to define a common framework for expressing policies at different 1076 levels of abstraction. SUPA uses the GPIM as a common vocabulary 1077 for representing policy concepts that are independent of language, 1078 protocol, repository, and level of abstraction. This enables 1079 different actors to author and use policies at different levels of 1080 abstraction. This forms a policy continuum [1] [2], where more 1081 abstract policies can be translated into more concrete policies, 1082 and vice-versa. 1084 Most systems define the notion of a policy as a single entity. 1085 This assumes that all users of policy have the same terminology, 1086 and use policy at the same level of abstraction. This is rarely, 1087 if ever, true in modern systems. The policy continuum defines a 1088 set of views (much like RM-ODP's viewpoints [9]) that are each 1089 optimized for an actor playing a specific role. SUPA defines the 1090 GPIM as a standard vocabulary and set of concepts that enable 1091 different actors to use different formulations of policy. This 1092 corresponds to the different levels in the policy continuum, and 1093 as such, can make use of previous experience in this area. 1095 It may be necessary to translate a Policy from a general to a more 1096 specific form (while keeping the abstraction level the same). For 1097 example, the declarative policy "Every network attached to a VM 1098 must be a private network owned by someone in the same group as 1099 the owner of the VM" may be translated to a more formal form (e.g., 1100 into Datalog, as in OpenStack Congress). It may also be necessary 1101 to translate a Policy to a different level of abstraction. For 1102 example, the previous Policy may need to be translated to a form 1103 that network devices can process directly. This requires a common 1104 framework for expressing policies that is independent of the level 1105 of abstraction that a Policy uses. 1107 4.2.1. Design Patterns 1109 A design pattern defines a reusable solution to a commonly occuring 1110 software design problem. It is not a finished solution, because of 1111 its generic nature. Rather, it is a "template" that outlines how to 1112 solve a problem that occurs in many different situations. 1114 In order to provide internal and external consistency, the SUPA 1115 Information Model uses several design patterns in key places withinhe 1116 the model. The following sub-sections describe three of the design 1117 patterns that this model uses. 1119 4.2.1.1. Composite Pattern 1121 One common issue is that some classes may need to be able to contain 1122 other classes. A common analogy is a folder system - folders can 1123 contain folders and files, but (typically) files do not contain 1124 folders. This is addressed by the Composite Pattern. 1126 The Composite Pattern creates a minimum of two subclasses, one for 1127 representing objects that can stand alone (e.g., files), and one for 1128 representing objects that serve as collections (e.g., folders). An 1129 example of this is SUPAECAPolicyRule. The composite subclass (e.g., 1130 SUPAECAPolicyRuleComposite) has an aggregating association back to 1131 or from the parent class (e.g., SUPAECAPolcyRule). This allows one 1132 to have composite entities which are made up of either other 1133 composites, or any of the atomic subclasses (e.g., 1134 SUPAECAPolicyRuleAtomic). 1136 While some models use recursive associations for this, experience 1137 has shown that this causes inappropriate associations, such as 1138 leading to an atomic subclass being able to contain more complex 1139 instances of the parent class. 1141 4.2.1.2. Decorator Pattern 1143 Another common issue is the need to have a highly extensible set of 1144 additional information that MAY need to be added for certain object 1145 instances. Some of this can be done with metadata, but often, the 1146 information to be added forms a part of the object instance behavior. 1147 This is addressed by the decorator pattern [11]. A good example is 1148 SUPAPolicyClause, whose definition and behavior can be extended 1149 dynamically at runtime by wrapping its object instance with 1150 other objects. This is explained below. 1152 An aggregation is defined between SUPAPolicyClause and the 1153 superclass of the set of classes that form the Decorator Pattern 1154 (i.e., SUPAPolicyClauseComponentDecorator). This aggregation 1155 enables zero or more concrete subclasses of the 1156 SUPAPolicyClauseComponentDecorator class to "wrap" (i.e., be 1157 attached to) the instance of the class being decorated (i.e., 1158 SUPAPolicyClause in this example). This has the effect of creating a 1159 new object that appears to be a SUPAPolicyClause, but contains new 1160 attributes and behavior that are added to the existing attributes 1161 and behavior of the SUPAPolicyClause. Clients that are using the 1162 decorated object (i.e., SUPAPolicyClause) are **not** aware of 1163 these changes. 1165 The SUPAPolicyClauseComponentDecorator class has a number of 1166 specific subclases that each represent additional kinds of 1167 information that can be attached to a SUPAPolicyClause object 1168 instance. In this example, concrete subclasses of SUPAPolicyTerm 1169 and SUPAECAComponent, along with SUPAPolicyCollection and other 1170 subclasses, define optional information that can be attached to a 1171 SUPAPolicyClause. More specifically, each concrete subclass of the 1172 SUPAPolicyClause class can be decorated by each concrete subclass of 1173 the SUPAPolicyClauseComponentDecorator class. This means that the 1174 SUPAPolicyClauseComponentDecorator object has an instance variable 1175 that holds a reference to a SUPAPolicyClause object. Since the 1176 SUPAPolicyClauseComponentDecorator object has the same interface as 1177 the SUPAPolicyClause object, the SUPAPolicyClauseComponentDecorator 1178 class (and all of its subclasses) are transparent to clients of the 1179 SUPAPolicyClause class (and its subclasses). Hence, all 1180 SUPAPolicyClauseComponentDecorator object instances can add 1181 attributes and/or methods to the concrete instance of the chosen 1182 subclass of SUPAPolicyClause. 1184 Figure 2 shows how this is done for methods. 1185 - Figure 2a shows the initial object to be wrapped 1186 - Figure 2b shows the SUPAPolicyEvent object wrapping the 1187 SUPAEncodedClause object 1188 - Figure 2c shows SUPAGenericDecoratedComponent object 1189 wrapping the SUPAPolicyEvent object. 1191 +-------------------+ 1192 | SUPAEncodedClause | 1193 | eval() | ===> 1194 +-------------------+ 1195 (a) Initial Object 1197 +------------------------+ 1198 | SUPAPolicyEvent | 1199 | eval() | 1200 | +-------------------+ | 1201 | | SUPAEncodedClause | | ===> 1202 | | eval() | | 1203 | +-------------------+ | 1204 +------------------------+ 1205 (b) SUPAPolicyEvent "wraps" SUPAEncodedClause 1207 +--------------------------------+ 1208 | SUPAGenericDecoratedComponent | 1209 | eval() | 1210 | +-----------------------+ | 1211 | | SUPAPolicyEvent | | 1212 | | eval() | | 1213 | | +-------------------+ | | 1214 | | | SUPAEncodedClause | | | 1215 | | | eval() | | | 1216 | | +-------------------+ | | 1217 | +-----------------------+ | 1218 +--------------------------------+ 1219 (c) SUPAGenericDecoratedComponent "wraps" SUPAPolicyEvent 1221 Figure 2. Conceptual Depiction of eval() Decorated Method 1223 When the eval() method is called in the outermost object 1224 (SUPAGenericDecoratedComponent), it delegates to the eval() method 1225 of SUPAPolicyEvent, which in turn delegates to the eval() method 1226 of SUPAEncodedClause. This method executes and returns the 1227 results to SUPAPolicyEvent, which executes and returns the results 1228 to SUPAGenericDecoratedComponent, which executes and returns the 1229 final result. 1231 In addition, decorators may be applied to decorators. This is 1232 accomplished by using a concrete subclass of the decorating classes 1233 (SUPAPolicyComponentDecorator), which then decorates a concrete 1234 subclass of the parent decorator (i.e., 1235 SUPAPolicyClauseComponentDecorator). This enables the basic 1236 information to have either individual decorations or complex 1237 decorator aggregates. 1239 4.2.2. Association Classes 1241 An association class enables attributes, operations, and other 1242 features to be added to an association. Consider the following 1243 example. An Employee can work for a Company, in which case the 1244 Company pays the Employee a salary. Now, where do you define the 1245 salary attribute? If you define the salary as part of the Company, 1246 then every Employee gets the same salary. If you define salary as 1247 an attribute of Employee, then that Employee gets the same salary 1248 for all Companies that the Employee works for. 1250 These problems result from the fact that different Employees can 1251 work for the same Company, and an Employee may also work for 1252 different Companies. Hence, the salary paid to the Employee is in 1253 reality a function of the relationship between Employee and 1254 Company, since the salary changes when the Employee works for a 1255 different Company. This is shown in Figure 3. 1257 C C 1258 +----------+ 1..n 0..n +---------+ 1259 | | IsEmployedBy | | 1260 | Employee +--------+-------+ Company | 1261 | | ^ | | 1262 +----------+ | +---------+ 1263 | 1264 C | 1265 +--------+-----------+ 1266 | IsEmployedByDetail | 1267 | | 1268 | salary : Float | 1269 | | 1270 +--------------------+ 1272 Figure 3. Using Association Classes 1274 Figure 3 shows that a class, named IsEmployedByDetail, is used to 1275 represent the semantics of the IsEmployedBy association. 1277 Note that an association class can define its own (i.e., class- 1278 level) attributes, methods, and relationships; all of these can be 1279 used to define the intended semantics of the association class. 1280 Note: class-level attributes, methods, and relationships are often 1281 called **static** attributes, methods, and relationships. 1282 Examples include: 1284 o restrict when the relationship can be established and/or 1285 terminated 1286 o restrict which classes of one end of the relationship can be 1287 associated with which classes from the other end of the 1288 relationship 1289 o define attributes that depend on both classes in the 1290 relationship 1292 In the above example, the use of a class enables the attributes of 1293 the association class (i.e., IsEmployedByDetail) to be used to 1294 define the salary attribute. This is because the salary attribute is 1295 a function of both the particular Employee being paid the salary 1296 and the Company that the Employee works for. In this example, we 1297 have chosen to give the salary attribute a datatype of type Float. 1299 Optionally, the association class can be subclassed to refine 1300 additional behavior. In addition, the association class can have 1301 its own set of relationships; these relationships could be used 1302 make the attributes of the association class dependent on 1303 other classes. 1305 4.3. SUPA Generic Policy Information Model Overview 1307 Figure 5 illustrates the approach for representing policy rules 1308 in SUPA. The top two layers are defined in this document; the 1309 bottom layer (Data Models) are defined in separate documents. 1310 Conceptually, the GPIM defines a set of objects that define the 1311 key elements of a Policy independent of how it is represented or 1312 its content. As will be shown, there is a significant difference 1313 between SUPAECAPolicyRules (see Section 6) and other types of 1314 policies (see Section 7). In principle, other types of SUPAPolicies 1315 could be defined, but the current charter is restricted to using 1316 only event-condition-action SUPAPolicies as exemplars. 1318 Note: the GPIM MAY be used without the EPRIM. However, in order to 1319 use the EPRIM, the GPIM MUST also be used. 1321 +----------------------------------------------+ 1322 | SUPA Generic Policy Information Model (GPIM) | 1323 +----------------------+-----------------------+ 1324 / \ 1325 | 1326 | 1327 +-----------------+--------------+ 1328 | | 1329 | | 1330 +-----------+---------------+ +-------------+-------------+ 1331 | SUPAECAPolicyRule | | Other Policy Models that | 1332 | Information Model (EPRIM) | | are Derived from the GPIM | 1333 +-----------+---------------+ +-------------+-------------+ 1334 / \ / \ 1335 | | 1336 | | 1337 +-----------+-----------+ +-----------+------------+ 1338 | ECAPolicyRule | | Other Types of | 1339 | Data Model | | Data Models | 1340 +-----------------------+ +------------------------+ 1342 Figure 5. Overview of SUPA Policy Rule Abstractions 1344 This draft defines the GPIM and EPRIM. This draft further assumes 1345 that the SUPA Information Model is made up of either the GPIM or the 1346 combination of the GPIM and the EPRIM. Extensions to both the GPIM 1347 and the EPRIM can be made as long as these extensions do not 1348 conflict with the content and structure defined in the GPIM and 1349 EPRIM. If the GPIM and EPRIM are part of another information model, 1350 then they should collectively still define a single information 1351 model. The GPIM defines the following concepts: 1353 o A class defining the top of the GPIM class hierarchy, called 1354 SUPAPolicyObject 1355 o Four subclasses of SUPAPolicyObject, representing: 1356 o the top of the Policy hierarchy, called 1357 SUPAPolicyStructure 1358 o the top of the Policy component hierarchy, called 1359 SUPAPolicyComponentStructure 1360 o PolicySource 1361 o PolicyTarget 1363 The SUPAPolicyStructure class is the superclass for all types of 1364 Policies (e.g., imperative, declarative, and others). This 1365 document is currently limited to imperative (e.g., ECA) policies. 1366 However, care has been taken to ensure that the attributes and 1367 relationships of the SUPAPolicyStructure class are extensible, 1368 and can be used for more types of policies than just ECA policies. 1370 This yields the following high-level structure: 1372 A 1373 +------------------+ 1374 | SUPAPolicyObject | 1375 +--------+---------+ 1376 / \ 1377 I 1378 I 1379 +----------------+--------------------+ 1380 I I I 1381 A I I A I 1382 +--------+------------+ I +------------+-----------------+ 1383 | SUPAPolicyStructure | I | SUPAPolicyComponentStructure | 1384 +----+----------------+ I +------------+-----------------+ 1385 / \ I / \ 1386 I +--------+----+ I 1387 I I I I 1388 I C I I I 1389 I +-------+----------+ I I 1390 I | SUPAPolicySource | I I 1391 I +------------------+ I I 1392 I I I 1393 I +-------------+ I 1394 I I +-----+-------+ 1395 I C I I I 1396 I +-------+----------+ A I I 1397 I | SUPAPolicyTarget | +--------+---------+ I 1398 I +------------------+ | SUPAPolicyClause | I 1399 A I +------------------+ I 1400 +-----+------------+ I 1401 | SUPAECAPolicyRule| A I 1402 +------------------+ +--------------------------+---------+ 1403 | SUPAPolicyClauseComponentDecorator | 1404 +------------------------------------+ 1406 Figure 6. Functional View of the Top-Level GPIM 1408 Note that all classes except the SUPAPolicySource and the 1409 SUPAPolicyTarget classes are defined as abstract. This provides 1410 more freedom for the data modeler in implementing the data model. 1411 For example, if the data model uses an object-oriented language, 1412 such as Java, then the above structure enables all of the abstract 1413 classes to be collapsed into a single concrete class. If this is 1414 done, attributes as well as relationships are inherited. 1416 4.3.1. SUPAPolicyObject 1418 A SUPAPolicyObject serves as a single root of the SUPA system 1419 (i.e., all other classes in the model are subclasses of the 1420 SUPAPolicyObject class) except for the Metadata objects, which are 1421 in a separate class hierarchy. This simplifies code generation and 1422 reusability. It also enables SUPAPolicyMetadata objects to be 1423 attached to any appropriate subclass of SUPAPolicyObject. 1425 4.3.2. SUPAPolicyStructure 1427 SUPAPolicyStructure is an abstract superclass that is the base 1428 class for defining different types of policies (however, in this 1429 version of this document, only ECA policy rules are modeled). It 1430 serves as a convenient aggregation point to define atomic (i.e., 1431 individual policies that can be used independently) and composite 1432 (i.e., hierarchies of policies) SUPAPolicies; it also enables 1433 PolicySources and/or PolicyTargets to be associated with a given 1434 set of Policies. 1436 SUPAPolicies are defined as either a stand-alone PolicyContainer 1437 or a hierarchy of PolicyContainers. A PolicyContainer specifies 1438 the structure, content, and optionally, source, target, and 1439 metadata information for a SUPAPolicy. This is implemented by the 1440 subclasses of SUPAPolicyStructure. For example, the composite 1441 pattern is used to create two subclasses of the SUPAECAPolicyRule 1442 class; SUPAECAPolicyRuleAtomic is used for stand-alone policies, 1443 and SUPAECAPolicyRuleComposite is used to build hierarchies of 1444 policies. 1446 This document defines a SUPAPolicy as an ECA Policy Rule, though 1447 the GPIM enables other types of policies to be defined and used 1448 with an ECA policy rule. The GPIM model is used in [2] and [5], 1449 along with extensions that allow [2] and [5] to define multiple 1450 types of policies that are derived from the GPIM. They also allow 1451 different combinations of different types of policy rules to be 1452 used with each other. Most previous work cannot define different 1453 types of policy rules; please see Appendix A for a comparison to 1454 previous work. 1456 4.3.3. SUPAPolicyComponentStructure 1458 SUPAPolicyComponentStructure is an abstract superclass that is the 1459 base class for defining components of different types of policies. 1460 SUPAPolicyStructure subclasses define the structure of a policy, 1461 while SUPAPolicyComponentStructure subclasses define the content 1462 that is contained in the structure of a policy. For example, a 1463 SUPAECAPolicyRule is an imperative policy rule, and defines its 1464 structure; its event, condition, and action clauses are populated 1465 by SUPAPolicyComponentStructure subclasses. The strength of this 1466 design is that different types of policies (e.g., imperative and 1467 declarative policies) can be represented using a common set of 1468 policy components. 1470 Please see the Appendix for a comparison to previous work. 1472 4.3.4. SUPAPolicyClause 1474 All policies derived from the GPIM are made up of one or more 1475 SUPAPolicyClauses, which define the content of the Policy. 1476 This enables a Policy of one type (e.g., ECA) to invoke Policies 1477 of the same or different types. SUPAPolicyClause is an abstract 1478 class, and serves as a convenient aggregation point for assembling 1479 other objects that make up a SUPAPolicyClause. 1481 The GPIM defines a single concrete subclass of SUPAPolicyClause, 1482 called SUPAEncodedClause. This is a generic clause, and can be 1483 used by any type of Policy in a stand-alone fashion. It can also 1484 be used in conjunction with other SUPAPolicyClauses. The EPRIM 1485 also defines a subclass of SUPAPolicyClause; see section 6.7). 1487 The structure of the GPIM is meant to provide an extensible 1488 framework for defining different types of policies. This is 1489 demonstrated by the EPRIM (see section 6) and the LSIM (see the 1490 Appendices) that each define new subclasses of SUPAPolicyClause 1491 (i.e., SUPABooleanClause and SUPALogicClause, respectively) 1492 without defining new classes that have no GPIM superclass. 1494 A SUPAPolicyClause is defined as an object. Therefore, clauses and 1495 sets of clauses are objects, which promotes reusability. 1497 4.3.5. SUPAPolicyClauseComponentDecorator 1499 One of the problems in building a policy model is the tendency to 1500 have a multitude of classes, and hence object instances, to 1501 represent different combinations of policy events, conditions, and 1502 actions. This can lead to class and/or relationship explosion. 1503 Please see Appendix A for a comparison to previous work. 1505 SUPAPolicyClauses are constructed using the Decorator Pattern 1506 [11]. This is a design pattern that enables behavior to be 1507 selectively added to an individual object, either statically or 1508 dynamically, without affecting the behavior of other objects from 1509 the same class. The decorator pattern uses composition, instead of 1510 inheritance, to avoid class and relationship explosion. The 1511 decorator pattern also enable new objects to be composed from 1512 parts or all of existing objects without affecting the existing 1513 objects. 1515 This enables the resulting SUPAPolicyClause to be constructed 1516 completely from objects in the SUPA information model. This 1517 facilitates the construction of policies at runtime by a machine. 1518 This is also true of [2] and [5]; however, this is NOT true of 1519 most other models. Please see Appendix A for a comparison to 1520 previous work. 1522 SUPAPolicyClauseComponentDecorator is the superclass for 4 classes 1523 in the GPIM, and one additional class in the EPRIM, that can be used 1524 to form a SUPAPolicyClause. Each of these five classes may be used 1525 with all other classes, if desired. These classes are: 1527 o SUPAPolicyTerm, which enables a clause to be defined in a 1528 canonical {variable, operator, value} form 1529 o SUPAGenericDecoratedComponent, which enabled a custom object 1530 to be defined and then used in a SUPAPolicyClause 1531 o SUPAPolicyCollection, which enables a collection of objects 1532 to be gathered together and associated with all or a portion 1533 of a SUPAPolicyClause 1534 o SUPAPolicyComponentDecorator, which enables additional 1535 Decorators to wrap the SUPAPolicyClauseComponentDecorator 1536 o SUPAECAComponent, which defines Events, Conditions, and 1537 Actions as reusable objects 1539 This approach facilitates the machine-driven construction of 1540 policies. Note that this is completely optional; policies do not 1541 have to use these constructs. 1543 4.3.6. SUPAPolicyTarget 1545 A SUPAPolicyTarget is a set of managed entities that a SUPAPolicy 1546 is applied to. A set includes individual and group membership. 1547 Data models implementations are free to populate the set using any 1548 appropriate mechanisms, such as reference by a property such as one 1549 or more roles, explicit lists, predicate expressions, or others. 1551 Note that the decision to define a managed entity as a 1552 SUPAPolicyTarget belongs with the management system; this 1553 model simply represents the fact that a given managed entity is 1554 defined as a SUPAPolicyTarget. Furthermore, the policy-based 1555 management system SHOULD ensure that the management entity 1556 performing the management operations has the proper permissions to 1557 perform the requested management operations. The design of the 1558 SUPAPolicyTarget addresses both of these criteria. 1560 4.3.7. SUPAPolicySource 1562 A SUPAPolicySource is a set of managed entities that authored, or 1563 are otherwise responsible for, this SUPAPolicy. Note that a 1564 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 1565 primary use is for auditability and the implementation of deontic 1566 and/or alethic logic. 1568 4.4. The Design of the GPIM 1570 The GPIM defines a policy as a type of PolicyContainer. For this 1571 version, only ECA Policy Rules will be described. However, it 1572 should be noted that the mechanism described is applicable to 1573 other types of policies (e.g., declarative) as well. 1575 4.4.1. Structure of Policies 1577 Recall that a PolicyContainer was defined as a special type of 1578 container that provides at least the following three functions: 1580 1. It uses metadata to define how its content is described 1581 and/or prescribed 1582 2. It separates the content of the policy from the 1583 representation of the policy 1584 3. It provides a convenient control point for OAMP operations. 1586 The first requirement is provided by the ability for any subclass 1587 of Policy (the root of the information model) to aggregate one or 1588 more concrete instances of a SUPAPolicyMetadata class. This is 1589 explained in detail in section 5.2.2. 1591 The second requirement is met by representing an ECA Policy as 1592 having two parts: (1) a rule part and (2) components that make up 1593 the rule. Since functional and declarative policies are not, 1594 strictly speaking, "rules", the former is named PolicyStructure, 1595 while the latter is named PolicyComponentStructure. 1597 The third requirement is met by the concrete subclasses of 1598 PolicyStructure. Since they are PolicyContainers, they are made 1599 up of the SUPAECAPolicyRule, its commponents, and any metadata 1600 that applies to the PolicyContainer, the SUPAECAPolicyRule, and.or 1601 any components of the SUPAECAPolicyRule. This provides optional 1602 low-level control over any part of the SUPAECAPolicyRule. 1604 The above requirements result in the design shown in Figure 7. 1606 A SUPAHasPolicyMetadata A 1607 +------------------+/ \ \+--------------------+ 1608 | SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata | 1609 +---------+--------+\ / /+--------------------+ 1610 / \ 0..n 0..n 1611 I 1612 I 1613 +------+------------------------------------+ 1614 I I 1615 A I A I 1616 +--------+------------+ +------------------+-----------+ 1617 | SUPAPolicyStructure | | SUPAPolicyComponentStructure | 1618 +--------+------------+ +-------------+----------------+ 1619 / \ / \ 1620 I I 1621 I I 1622 (subclasses representing (subclasses representing 1623 different types of policies) different policy components) 1625 Figure 7. Structure of a Policy 1627 Note that aggregation in Figure 7 (named SUPAHasPolicyMetadata) 1628 is realized as an association class, in order to manage which set 1629 of Metadata can be aggregated by which SUPAPolicyObject. The 1630 combination of these three functions enables a PolicyContainer 1631 to define the behavior of how its constituent components will be 1632 accessed, queried, stored, retrieved, and how they operate. 1634 It is often necessary to construct groups of policies. The GPIM 1635 follows [2] and [5], and uses the composite pattern [11] to 1636 implement this functionality, as shown in Figure 8 below. There 1637 are a number of advantages to using the composite pattern over a 1638 simple relationship, as detailed in [11]. 1640 Figure 8 shows that SUPAPolicyStructure has a single subclass, 1641 called SUPAECAPolicyRule. Note, however, that other types of 1642 policies, such as declarative policies, can be defined as 1643 subclasses of SUPAPolicyStructure in the future. 1645 A 1646 +---------------------+ 1647 | SUPAPolicyStructure | 1648 +--------+------------+ 1649 / \ 1650 I 1651 I 1652 +---------------+----------------+ 1653 I I 1654 C I A I 1655 +----------------+---------------+ +-----------+-----------+ 1656 | Future Subclasses to Represent | | SUPAECAPolicyRule | 1657 | Represent Different Policies | +-----------------------+ 1658 +--------------------------------+ 1660 Figure 8. The Composite Pattern Applied to SUPAPolicyStructure 1662 4.4.2. Representing an ECA Policy Rule 1664 An ECA policy rule is a 3-tuple, which is made up of an event 1665 clause, a condition clause, and an action clause. Each of these 1666 three types of clauses may in turn be made up of a Boolean 1667 combination of clauses of that type. Each clause may be viewed as 1668 a predicate, as it provides a TRUE or FALSE output. The canonical 1669 form of a clause is a 3-tuple of the form "variable operator value", 1670 and can be made into more complex Boolean expressions. For example, 1671 the SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two 1672 clauses, "(A AND B)" and "(C OR D)", that are combined together 1673 using the operators OR and NOT. 1675 A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract 1676 subclass of SUPAPolicyStructure. 1678 Note that the aggregation SUPAHasPolicyClause in Figure 9 is 1679 realized as an association class, in order to manage which set 1680 of SUPAPolicyClauses can be aggregated by which set of 1681 SUPAECAPolicyRules. This aggregation is defined at the 1682 SUPAPolicyStructure level, and not at the lower level of 1683 SUPAECAPolicyRule, so that non-ECA policies can also use this 1684 aggregation. 1686 A A 1687 +---------------------------+ +------------------+ 1688 | SUPAPolicyStructure | | SUPAPolicyClause | 1689 +---------+---------+-------+ +----------+-------+ 1690 / \ / \ 0..1 1..n / \ 1691 I A | 1692 I \ / | 1693 I | | 1694 I | SUPAHasPolicyClause | 1695 I +---------------+----------+ 1696 A I I 1697 +--------+----------+ A I 1698 | SUPAECAPolicyRule | +--------+------------------+ 1699 +-------------------+ | SUPAHasPolicyClauseDetail | 1700 +---------------------------+ 1702 Figure 9. SUPAECAPolicyRule Aggregating SUPAPolicyClauses 1704 Since a SUPAECAPolicyRule consists of three SUPAPolicyClauses, 1705 at least three separate instances of the SUPAHasPolicyClause 1706 aggregation are instantiated in order to make a complete 1707 SUPAECAPolicyRule, as shown in Figure 10. 1709 A A 1710 +-------------------+ +--------------------+ 1711 | SUPAECAPolicyRule | | SUPAPolicyClause | 1712 +--+----+----+------+ +-------+----+----+--+ 1713 / \ / \ / \ 0..1 1..n / \ / \ / \ 1714 A A A | | | 1715 \ / \ / \ / | | | 1716 | | | | | | 1717 | | | SUPAHasPolicyClause #1 | | | 1718 | | +------------------------------+ | | 1719 | | | | 1720 | | SUPAHasPolicyClause #2 | | 1721 | +----------------------------------------+ | 1722 | | 1723 | SUPAHasPolicyClause #3 | 1724 +--------------------------------------------------+ 1726 note: all 3 aggregations have a multiplicity of 0..1 - 1..n 1728 Figure 10. Instantiating a SUPAECAPolicyRule, part 1 1730 In figure 10, SUPAECAPolicyRule is shown as "owning" these three 1731 aggregations, since it inherits them from its superclass 1732 (SUPAPolicyStructure). The three aggregations represent the 1733 event, condition, and action clauses of a SUPAECAPolicyRule. 1734 Note that each of these clauses MAY consist of one or more 1735 SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist 1736 of one or more predicates. In this way, complex event, condition, 1737 and action clauses, which are combinations of Boolean expressions 1738 that form a logical predicate) are supported, without having to 1739 define additonal objects (as is done in previous work; please 1740 see Appendix A for a comparison to previous work. 1742 The multiplicity of the SUPAHasPolicyClause aggregation is 1743 0..n on the aggregate side and 1..n on the part side. This means 1744 that a particular SUPAECAPolicyRule MUST aggregate at least one 1745 SUPAPolicyClause, and that a given SUPAPolicyClause MAY be 1746 aggregated by zero or more SUPAECAPolicyRule objects. 1748 This cardinality MAY be refined to 3..n for SUPAECAPolicyRules, 1749 since a SUPAECAPolicyRule MUST have at least three separate clauses. 1750 However, since a SUPAPolicyStructure is the owner of this 1751 aggregation (which is inherited by SUPAECAPolicyRule), the 1752 cardinality is defined to be 1..n on the part side because other 1753 types of Policies have different needs. The 0..n cardinality 1754 means that a SUPAPolicyClause may be aggregated by zero or more 1755 SUPAECAPolicyRules. The zero is provided so that SUPAPolicyClauses 1756 can be stored in (for example) a repository before the 1757 SUPAECAPolicyRule is created; the "or more" recognizes the fact 1758 that multiple SUPAECAPolicyRules could aggregate the same 1759 SUPAPolicyClause. 1761 In Figure 10, suppose that SUPAHasPolicyClause#1, #2, and #3 1762 represent the aggregations for the event, condition, and action 1763 clauses, respectively. This means that each of these 1764 SUPAHasPolicyClause aggregations must explicitly identify the 1765 type of clause that it represents. 1767 In looking at Figure 10, there is no difference between any of the 1768 three aggregations, except for the type of clause that the 1769 aggregation represents (i.e., event, condition, or action clause). 1771 Therefore, three different aggregations, each with their own 1772 association class, is not needed. Instead, the GPIM defines a 1773 single aggregation (SUPAHasPolicyClause) that is realized using a 1774 (single) abstract association class (SUPAHasPolicyClauseDetail); 1775 this association class is then subclassed into three concrete 1776 subclasses, one each to represent the semantics for an event, 1777 condition, and action clause. 1779 The policy management system may use any number of different 1780 software mechanisms, such as introspection or reflection, to 1781 determine the nature of the aggregation (i.e., what object types 1782 are being aggregated) in order to select the appropriate subclass 1783 of SUPAHasPolicyClauseDetail. The three subclasses of 1784 SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail, 1785 SUPAHasPolicyConditionDetail, and SUPAHasPolicyActionDetail, 1786 respectively. While Event, Condition, and Action objects are 1787 typically used in ECA policy rules, the design in this document 1788 enables them to be used as policy components of other types of 1789 policies as well. This is shown in Figure 11. 1791 A A 1792 +-------------------+ +------------------+ 1793 | SUPAECAPolicyRule | | SUPAPolicyClause | 1794 +---------+---------+ +----------+-------+ 1795 / \ 1..n 0..n / \ 1796 A | 1797 \ / | 1798 | | 1799 | SUPAHasPolicyClause | 1800 +--------------+-----------------+ 1801 ^ 1802 | 1803 A | 1804 +--------------+------------+ 1805 | SUPAHasPolicyClauseDetail | 1806 +--------------+------------+ 1807 / \ 1808 I 1809 I 1810 +----------------+-----------------------+ 1811 I I I 1812 C I C I C I 1813 +--------+-----+ +-------+----------+ +---------+-----+ 1814 |Event subclass| |Condition subclass| |Action subclass| 1815 +--------------+ +------------------+ +---------------+ 1817 Figure 11. Instantiating a SUPAECAPolicyRule, part 2 1819 4.4.3. Creating SUPA Policy Clauses 1821 There are two different types of Policy Components. They are a 1822 SUPAPolicyClause and a SUPAPolicyClauseComponentDecorator. The 1823 former is used to construct SUPAECAPolicyRules, while the latter 1824 is used to add behavior to a SUPAPolicyClause. This enables the 1825 structure and capabilities of the SUPAPolicyClause to be adjusted 1826 dynamically at runtime. This is shown in Figure 12. 1828 A 1829 +------------------------------+ 1830 | SUPAPolicyComponentStructure | 1831 +---------------+--------------+ 1832 / \ 1833 I 1834 I 1835 +---------------+--------------------+ 1836 | | 1837 A | A | 1838 +--------+---------+ +---------------+--------------------+ 1839 | | | | 1840 | SUPAPolicyClause | | SUPAPolicyClauseComponentDecorator | 1841 | | | | 1842 +------------------+ +---------------------------+--------+ 1843 / \ 0..n 0..n / \ 1844 A | 1845 \ / | 1846 | | 1847 | SUPAPolicyClauseHasDecorator | 1848 +--------------------------------------------------+ 1850 Figure 12. Decorating SUPAPolicyClauses 1852 Every SUPAPolicyClause can be made up of a variable number of 1853 SUPAPolicyClauseComponentDecorators, so the multiplicity of the 1854 SUPAPolicyClauseHasDecorator aggregation is 0..n - 0..n. This means 1855 that a SUPAPolicyClause may have zero or more decorating objects, 1856 and that a SUPAPolicyClauseComponentDecorator MAY be associated with 1857 zero or more SUPAPolicyClauses. Note that the "zero" part of this 1858 multiplicity enables SUPAPolicyClauseComponentDecorator objects to 1859 be stored in a PolicyRepository without having to be bound to ability 1860 particular SUPAPolicyClause. The use of the decorator pattern avoids 1861 problems encountered in earlier models, which resulted in a 1862 proliferation of classes and relationships. 1864 Instead of using inheritance to statically create new classes to 1865 represent new types of objects, the decorator pattern uses 1866 composition to dynamically combine attributes and behavior from 1867 existing objects into new objects. This is done by defining an 1868 interface in SUPAPolicyComponent that all of the subclasses of 1869 SUPAPolicyComponent conform to. Since the subclasses are of the 1870 same type as SUPAPolicyComponent, they all have the same interface. 1871 This allows each concrete SUPAPolicyClauseComponentDecorator 1872 subclass to add its attributes and/or behavior to the concrete 1873 subclass of SUPAPolicyClause that it is decorating (or "wrapping"). 1875 This represents an important design optimization for data models. 1876 Note that a single SUPAECAPolicyRule can consist of any number of 1877 SUPAPolicyClauses, each of very different types. If inheritance 1878 was used, then a subclass AND an aggregation would be required for 1879 each separate clause that makes up the policy rule. 1881 Suppose composite objects are desired (e.g., a new object Foo is 1882 made up of existing objects Bar and Baz). If all that was needed 1883 was one attribute of Bar and two of Baz, the developer would still 1884 have to use the entire Bar and Baz classes. This is wasteful and 1885 inefficient. In contrast, the decorator pattern enables all, or 1886 just some, of the attributes and/or behavior of a class to "wrap" 1887 another class. This is used heavily in many production systems 1888 (e.g., the java.io package) because the result is only the 1889 behavior that is required, and no other objects are affected. 1891 SUPAPolicyClauseComponentDecorator is the superclass of five 1892 subclasses, as shown in Figure 13. 1894 A 1895 +------------------------------------+ 1896 | SUPAPolicyClauseComponentDecorator | 1897 +-----------------+------------------+ 1898 / \ 1899 I 1900 I 1901 I 1902 +------------+-+-----------+------------------+ 1903 I I I I I 1904 A I I I C I I 1905 +--------+-------+ I I +---------+------------+ I 1906 | SUPAPolicyTerm | I I | SUPAPolicyCollection | I 1907 +----------------+ I I +----------------------+ I 1908 (for defining I I (for defining sets and/or I 1909 clauses in a I I groups of objects) I 1910 canonical form) I I I 1911 I +---------------+ I 1912 C I I A I 1913 +----------------+--------------+ I +---------+--------+ 1914 | SUPAGenericDecoratedComponent | I | SUPAECAComponent | 1915 +-------------------------------+ I +------------------+ 1916 (for decorating concrete I (for defining reusable 1917 subclasses of SUPAPolicyClause) I event, condition, 1918 I and action objects) 1919 I 1920 A I 1921 +-------------+----------------+ 1922 | SUPAPolicyComponentDecorator | 1923 +------------------------------+ 1924 (for decorating SUPAPolicyClauseComponentDecorator 1925 objects with SUPAPolicyComponentDecorator objects) 1927 Figure 13. Subclasses of SUPAPolicyClauseComponentDecorator 1929 The SUPAPolicyClauseComponentDecorator class hierarchy is used to 1930 define classes that may be used to construct a SUPAPolicyClause. The 1931 decorator object can add behavior before, and/or after, it 1932 delegates to the object that it is decorating. The subclasses of 1933 SUPAPolicyClauseComponentDecorator provide a very flexible and 1934 completely dynamic mechanism to: 1936 1) add or remove behavior to/from a SUPAPolicyClause object 1937 2) ensure that objects are constructed using the minimum amount 1938 of features and functionality required 1940 If a SUPAEncodedClause is being used, then there is no need to 1941 use any of the SUPAPolicyClauseComponentDecorator subclasses, since 1942 the SUPAEncodedClause already completely defines the content of 1943 the SUPAPolicyClause. 1945 However, if a SUPAEncodedClause is NOT being used, then a 1946 SUPAPolicyClause SHOULD be constructed using one or more types of 1947 concrete subclasses of SUPAPolicyClauseComponentDecorator. 1949 These five subclasses provide five different ways to construct a 1950 SUPAPolicyClause: 1952 1) SUPAPolicyTerm: as a {variable, operator, value} clause 1953 2) SUPAGenericDecoratedComponent: as an encoded object (e.g., to 1954 pass YANG or CLI code) 1955 3) SUPAPolicyCollection: as a collection of objects that 1956 requires further processing in order to be made into a 1957 SUPAPolicyClause 1958 4) SUPAECAComponent: subclasses define reusable Event, 1959 Condition, or Action objects 1960 5) SUPAPolicyComponentDecorator: as a new type of Decorator to 1961 augment any of the above four mechanisms 1963 These four different types of objects can be intermixed. For 1964 example, the first and fourth types can be combined as follows: 1966 Variable == Event.baz (A) 1967 Condition BETWEEN VALUE1 and VALUE2 (B) 1968 (Event.severity == 'Critical' AND 1969 (SLA.violation == TRUE OR User.class == 'Gold')) (C) 1971 In the above rules, (A) uses Event.baz to refer to an attribute 1972 of the Event class; (B) defines two different instances of a Value 1973 class, denoted as Value1 and Value2; (C) uses the nomenclature 1974 foo.bar, where foo is the name of a class, and bar is the name of 1975 an attribute of that class. 1977 4.4.4. Creating SUPAPolicyClauses 1979 The GPIM defines a single subclass of SUPAPolicyClause, called 1980 SUPAEncodedClause. This clause is generic in nature, and MAY be 1981 used with any type of policy (ECA or otherwise). The EPRIM 1982 defines an ECA-specific subclass of the GPIM, called a 1983 SUPABooleanClause, which is intended to be used with just 1984 ECA policy rules; however, other uses are also possible. 1986 Together, the GPIM and EPRIM provide several alternatives to 1987 implement a SUPAPolicyClause, enabling the developer to 1988 optimize the solution for different constraints: 1990 1) The SUPAPolicyClause can be encoded using one or more 1991 SUPAEncodedClauses; a SUPAEncodedClause encodes the 1992 entire content of its respective event, condition, or 1993 action clause. 1994 2) The SUPAPolicyClause can be defined using one or more 1995 SUPABooleanClauses; each of the three clauses can be 1996 defined as either a single SUPABooleanClause, or a 1997 combination of SUPABooleanClauses that are logically 1998 ANDed, ORed, and/or NOTed. 1999 3) The above two mechanisms can be combined (e.g., the first 2000 used to define the event clause, and the second used to 2001 define the condition and action clauses). 2003 Figure 14 shows the subclasses of SUPAPolicyClause. 2005 A 2006 +------------------+ 2007 | SUPAPolicyClause | 2008 +--------+---------+ 2009 / \ 2010 I 2011 I 2012 I 2013 +---------------+-------------+ 2014 I I 2015 A I C I 2016 +--------+----------+ +----------+--------+ 2017 | SUPABooleanClause | | SUPAEncodedClause | 2018 +-------------------+ +-------------------+ 2020 Figure 14. Subclasses of SUPAPolicyClause 2022 SUPABooleanClause (see Section 6.7) is defined in the EPRIM, and is 2023 used to construct Boolean clauses that collectively make up a 2024 SUPAPolicyClause. It is abstract, so that the composite pattern 2025 can be applied to it, which enables hierarchies of Boolean 2026 clauses to be created. SUPAEncodedClause (see section 5.6) is 2027 used to encode the content of a SUPAPolicyClause as an attribute 2028 (instead of reusable objects). 2030 4.4.5. SUPAPolicySources 2032 A SUPAPolicySource is a set of managed entities that authored, 2033 or are otherwise responsible for, this SUPAPolicy. Note that a 2034 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 2035 primary use is for auditability, authorization policies, and 2036 other applications of deontic and/or alethic logic. 2038 The SUPAHasPolicySource aggregation defines the set of 2039 SUPAPolicySource objects that are sources for a given SUPAPolicy 2040 (as defined by a concrete subclass of SUPAPolicyStructure). Since 2041 SUPAECAPolicyRule is a subclass of SUPAPolicyStructure, it (and 2042 its subclasses) inherit this aggregation. This enables a set of 2043 SUPAPolicySource objects to be attached to a particular 2044 SUPAECAPolicyRule object. 2046 Figure 15 shows how SUPAPolicySources and SUPAPolicyTargets are 2047 attached to a SUPAPolicy. Note that both of these aggregations 2048 are defined as optional, since their multiplicity is 0..n - 0..n. 2049 In addition, both of these aggregations are realized as 2050 association classes, in order to be able to control which 2051 SUPAPolicySources and SUPAPolicyTargets are attached to a given 2052 SUPAECAPolicyRule. 2054 A 2055 +------------------+ 2056 | SUPAPolicyObject | 2057 +--------+---------+ 2058 / \ 2059 I 2060 I 2061 +--------------+-----+---------------------+ 2062 I I I 2063 A I C I C I 2064 +-----------+---------+ +-------+--------+ +--------+-------+ 2065 | SUPAPolicyStructure | |SUPAPolicySource| |SUPAPolicyTarget| 2066 +------+-------+------+ +----------+-----+ +----------+-----+ 2067 0..n / \ / \ 0..n 0..n / \ 0..n / \ 2068 A A | | 2069 \ / \ / | | 2070 | | | | 2071 | | | | 2072 | +--------------------+ | 2073 | SUPAHasPolicySource | 2074 | | 2075 +-------------------------------------------------+ 2076 SUPAHasPolicyTarget 2078 Figure 15. ECAPolicyRules, SUPAPolicySources, and PolicyTargets 2080 A SUPAPolicySource MAY be mapped to a role (e.g., using the 2081 role-object pattern [11]); this indirection makes the system less 2082 fragile, as entities can be transparently added or removed from 2083 the role definition without adversely affecting the definition of 2084 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 2085 SUPAPolicyMetadata. 2087 4.4.6. SUPAPolicyTargets 2089 A SUPAPolicyTarget defines the set of managed entities that a 2090 SUPAPolicy is applied to. This is useful for debugging, as well as 2091 when the nature of the application requires the set of managed 2092 entities affected by a Policy to be explicitly identified. This is 2093 determined by two conditions: 2095 1) The set of managed entities that are to be affected by the 2096 SUPAPolicy must all agree to play the role of a 2097 SUPAPolicyTarget. For example, a managed entity may not be 2098 in a state that enables SUPAPolicies to be applied to it; 2099 hence, in this case, it MUST NOT assume the role of a 2100 SUPAPolicyTarget 2101 2) A SUPAPolicyTarget must be able to: 2102 a) process (either directly or with the aid of a proxy) 2103 SUPAPolicies, or 2104 b) receive the results of a processed SUPAPolicy and 2105 apply those results to itself. 2107 Figure 15 showed how SUPAPolicyTargets are attached to 2108 SUPAECAPolicyRules. 2110 The SUPAHasPolicyTarget aggregation defines the set of 2111 SUPAPolicyTarget objects that are targets for (e.g., will be acted 2112 on) by a given SUPAPolicy (as defined by a concrete subclass of 2113 SUPAPolicyStructure). Since SUPAECAPolicyRule is a subclass of 2114 SUPAPolicyStructure, it (and its subclasses) inherit this 2115 aggregation. This enables a set of SUPAPolicyTarget objects to be 2116 attached to a particular SUPAECAPolicyRule object. 2118 A SUPAPolicyTarget MAY be mapped to a role (e.g., using the 2119 role-object pattern [11]); this indirection makes the system less 2120 fragile, as entities can be transparently added or removed from 2121 the role definition without adversely affecting the definition of 2122 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 2123 SUPAPolicyMetadata. 2125 4.4.7. Policy Metadata 2127 Metadata is, literally, data about data. As such, it can be 2128 descriptive or prescriptive in nature. 2130 4.4.7.1. Motivation 2132 There is a tendency in class design to make certain attributes, 2133 such as description, status, validFor, and so forth, bound to a 2134 specific class (e.g., [6]). This is bad practice in an information 2135 model. For example, different classes in different parts of the 2136 class hierarchy could require the use of any of these attributes; 2137 if one class is not a subclass of the other, then they must each 2138 define the same attribute as part of their class structure. This 2139 makes it difficult to find all instances of the attribute and 2140 ensure that they are synchronized. Furthermore, context can 2141 dynamically change the status of an object, so an easy way to 2142 update the status of one object instance without affecting other 2143 instances of the same object is required. 2145 Many models, such as [4] and [6], take a simplistic approach of 2146 defining a common attribute high in the hierarchy, and making it 2147 optional. This violates classification theory, and defeats the 2148 purpose of an information model, which is to specify the 2149 differences in characteristics and behavior between classes (as 2150 well as define how different classes are related to each other). 2151 Note that this also violates a number of well-known software 2152 architecture principles, including: 2154 o the Liskov Substitution Principle [13] 2155 (if A is a subclass of B, then objects instantiated from 2156 class B may be replaced with objects instantiated from 2157 class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS) 2158 o the Single Responsibility Principle [14] 2159 (every class should have responsibility over one, and only 2160 one, part of the functionality provided by the program) 2161 o the Open/Closed Principle (software should be open for 2162 extension, but closed for modification) [17] 2163 o the Interface-Segreation Principle (clients should not be 2164 forced to depend on methods that they do not use) [14] 2165 o the Dependency Inversion Principle (high-level modules should 2166 not depend on low-level modules; both should depend on 2167 abstractions) [14] 2169 Most models use inheritance, not composition. The former is 2170 simpler, but has some well-known problems. One is called "weak 2171 encapsulaton", meaning that a subclass can use attributes and 2172 methods of a superclass, but if the superclass changes, the 2173 subclass may break. Another is that each time a new object is 2174 required, a new subclass must be created. These problems are 2175 present in [RFC3460], [4], and [6]. 2177 Composition is an alternative that provides code that is easier to 2178 use. This means that composition can provide data models that are 2179 more resistant to change and easier to use. By using composition, 2180 we can select just the metadata objects that are needed, instead 2181 of having to rely on statically defined objects. We can even 2182 create new objects from a set of existing objects through 2183 composition. Finally, we can use the decorator pattern to select 2184 just the attributes and behaviors that are required for a given 2185 instance. 2187 In [2] and [5], a separate metadata class hierarchy is defined to 2188 address this problem. This document follows this approach. 2190 4.4.7.2. Design Approach 2192 The goal of the GPIM is to enable metadata to be attached to any 2193 subclass of SUPAPolicyObject that requires it. Since this is a 2194 system intended for policy-based management, it therefore makes 2195 sense to be able to control which metadata is attached to which 2196 policies dynamically (i.e., at runtime). 2198 One solution is to use the Policy Pattern [1], [2], [6], [12]. 2199 This pattern was built to work with management systems whose 2200 actions were dependent upon context. The Policy Pattern is shown 2201 in Figure 16, and works as follows: 2203 Defines 2204 +----------+ Behavior +------------+ 2205 | Policies +----------------+ | SUPAPolicy | 2206 +----+-----+ 1..n | +------+-----+ 2207 0..n / \ | / \ 0..n 2208 | | A 2209 | | \ / 2210 | 1..n \ / | 2211 | +-----------+--------------+ | 2212 | | SUPAPolicyMetadataDetail | | 2213 | +-----------+--------------+ | 2214 | | | 2215 | Selects | | 2216 | Policies | | 2217 | | | 2218 | +-------------------->+ 2219 | Applies | 2220 / \ Behavior | 2221 A | 2222 0..n \ / \ / 0..n 2223 +----+-----+ +--------+---------+ 2224 | Context | |SUPAPolicyMetadata| 2225 +----------+ +------------------+ 2227 Figure 16. Context-Aware Policy Rules 2229 o Context is derived from all applicable system inputs (e.g., 2230 OAMP data from network elements, business goals, time of 2231 day, geo-location, etc.). 2232 o Context is then used to select a working set of Policies. 2233 o Policies are then used to define behavior at various 2234 control points in the system. 2235 o One simple type of control point is an association class. 2236 Since the association class represents the semantics of how 2237 two classes are related to each other, then 2238 o ECAPolicyRule actions can be used to change the attribute 2239 values, methods, and relationships of the association 2240 class 2241 o This has the affect of changing how the two classes are 2242 related to each other 2243 o Finally, as context changes, the working set of policies 2244 change, enabling the behavior to be adjusted to follow 2245 changes in context (according to appropriate business goals 2246 and other factors, of course) in a closed loop manner. 2248 4.4.7.2.1. Policies and Actors 2250 The Policy Continuum ([1] [5] [10] [12]) was defined to associate 2251 different actors with different policies at different levels of 2252 business and/or technical specificity. Context-aware policy rules, 2253 and the Policy Pattern, were defined to realize this association. 2255 Four important functions related to the lifecycle of policies are 2256 design, implementation, deployment, and execution. There are many 2257 different possible definitions of these functions (even for policy 2258 lifecycle management); however, for the purposes of this document, 2259 they are defined as follows: 2261 o Design: The process of defining a software architecture 2262 to satisfy user requirements. 2263 o Development: the process of documenting, programming, 2264 testing, and maintaining code and applications 2265 as part of a software product 2266 o Deployment: the process that assembles and transfers 2267 completed software artifacts to a state that 2268 enables their execution 2269 o Execution: the process of installing, activating, running, 2270 and subsequently deactivating executable 2271 software products 2273 The design process is responsible for producing a software 2274 architecture. This emphasizes the design, as opposed to the 2275 programming, of software systems. In contrast to design, 2276 development emphasizes constructing software artifacts via coding 2277 and documentation. 2279 Deployment may be described as the process of releasing software. 2280 It includes all of the operations required to assemble a completed 2281 software product. It typically also includes the process of 2282 preparing a software product for execution (e.g., assembling a set 2283 of software products into a larger product, determining if the 2284 consumer site has appropriate resources to install and execute the 2285 software product, and collecting information on the feasibility of 2286 using the software product). This contrasts with the execution 2287 process, which is the set of processes that follow deployment. 2289 In summary, exemplar states in the policy lifecycle process 2290 include: 2292 o Design: determining how the policy-based management 2293 system will operate 2294 o Development: documenting, programming, testing, and 2295 maintaining policies and policy components 2296 o Deployment: assembling the components of a policy-based 2297 management system 2298 o Execution: installing, enabling, running, disabling, 2299 and uninstalling policies and policy components 2301 4.4.7.2.2. Deployment vs. Execution of Policies 2303 One of the primary reasons for separating the deployment and 2304 execution processes is to differentiate between environments that 2305 are not ready to execute policies (i.e., deployment) and 2306 environments that are ready to execute policies (i.e., execution). 2307 This is an important consideration, since policies that are 2308 related to the same set of tasks may be deployed in many different 2309 places (e.g., in a policy system vs. in a network device). In 2310 addition, each managed entity in the set of SUPAPolicyTargets may 2311 or may not be in a state that allows SUPAPolicies to be applied to 2312 it (see section 4.4.6.). 2314 Hence, this design includes dedicated class attributes for 2315 getting and setting the deployment and execution status, as well 2316 as enabling and disabling, SUPAPolicies (see section 5.3.1.). 2318 4.4.7.2.3. Using SUPAMetadata for Policy Deployment and Execution 2320 One way of encoding deployment and execution status for policies 2321 and policy components is to attach Metadata objects to affected 2322 SUPAPolicyStructure and SUPAPolicyComponentStructure objects. 2323 This provides an extensible and efficient means to describe 2324 and/or prescribe deployment and/or execution status of a policy 2325 or a policy component. It is extensible, since classes and 2326 relationships can be used, as opposed to a set of attributes. It 2327 is efficient, because the decorator pattern (see section 5.7) is 2328 used (this enables attributes and/or methods of objects, or the 2329 entire object, to be used to add characteristics and/or behavior 2330 to a given object. 2332 SUPAPolicyMetadata objects (see sections 5.16 - 5.20) may be 2333 attached to the SUPAECAPolicyRule and/or any of its components 2334 to define additional semantics of the SUPAECAPolicyRule. For 2335 example, SUPAAccessMetadataDef (see section 5.19) and/or 2336 SUPAVersionMetadataDef (see section 5.20) may be attached to 2337 define the access privileges and version information, 2338 respectively, of a policy rule and/or its components. 2340 The SUPAPolicyStructure defines an attribute, supaPolDeployStatus, 2341 (see section 5.3.1.3.) that SUPAPolicyMetadata objects can 2342 use to get and set the deployment and execution status of a 2343 SUPAPolicy. This allows metadata to be used to alter the 2344 deployment and/or execution state of a policy (or a set of 2345 policy components) without having to affect other parts of the 2346 policy-based management system. The supaPolDeployStatus attribute 2347 indicates that this SUPAPolicy can or cannot be deployed. If it 2348 cannot be deployed. 2350 The reverse is also true (and hence, forms a closed-loop system 2351 controlled by metadata). For example, if the set of deployed 2352 SUPAPolicies are SUPAECAPolicyRules, then when the actions of 2353 these SUPAECAPolicyRules are executed, the overall context has 2354 changed (see section 4.4.7.2). The context manager could then 2355 change attribute values (directly or indirectly) in the 2356 SUPAPolicyMetadataDetail association class. This class represents 2357 the behavior of the SUPAHasPolicyMetadata aggregation, which is 2358 used to define which SUPAPolicyMetadata can be attached to which 2359 SUPAPolicy objet in this particular context. For example, the 2360 access privileges of a policy and/or policy component could be 2361 changed dynamically, according to changes in context. 2363 By using the decorator pattern on SUPAPolicyMetadata, any number 2364 of SUPAPolicyMetadata objects (or their attributes, etc.) can be 2365 wrapped around a concrete subclass of SUPAPolicyMetadata. This is 2366 shown in Figure 17 below. 2368 4.4.7.3. Structure of SUPAPolicyMetadata 2370 SUPAPolicyMetadata also uses the decorator pattern to provide an 2371 extensible framework for defining metadata to attach to SUPAPolicy 2372 subclasses. Its two principal subclasses are 2373 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. The 2374 former is used to define concrete subclasses of SUPAPolicyMetadata 2375 that are attached at runtime to SUPAPolicy subclasses, while the 2376 latter is used to define concrete objects that represent reusable 2377 attributes, methods, and relationships that can be added to 2378 subclasses of SUPAPolicyConcreteMetadata. 2380 For example, concepts like identification, access control, and 2381 version information are too complex to represent as a single 2382 attribute, or even a couple of attributes - they require the 2383 generic power of objects to represent their characteristics and 2384 behavior. Furthermore, defining concrete classes to represent 2385 these concepts in the policy hierarchy is fragile, because: 2387 1. not all objects that use these concepts need all of the 2388 information represented by them (e.g., two subclasses of an 2389 Identification Object may be Passport and Certificate, but 2390 these two objects are rarely used together, and even those 2391 contexts that use one of these classes may not need all of 2392 the data in that class) 2393 2. defining a class means defining its attributes, methods, and 2394 relationships at a particular place in the hierarchy; this 2395 means that defining a relationship between a class A and 2396 another class B SHOULD only be done if all of the subclasses 2397 of B can use the attributes, methods, and relationships of A 2398 (e.g., in the above example, defining a relationship between 2399 an Identification Object and a superclass of a router class 2400 is not appropriate, since routers do not use Passports) 2402 Therefore, an association class is used to define the semantics 2403 of the SUPAHasPolicyMetadata aggregation. This follows the strategy 2404 defined in Section 4.2.2. Figure 17 illustrates this approach. The 2405 SUPAHasPolicyMetadataDetail association class contains attributes 2406 that define which SUPAPolicyMetadata objects can be aggregated by 2407 which SUPAPolicyObjects. This also enables SUPAPolicies to be 2408 defined that get and set the values of these attributes. (Note that 2409 for this approach to work, the association class is defined as a 2410 concrete class.) The multiplicity of the SUPAHasPolicyMetadata 2411 aggregation is defined as 0..n - 0..n, which makes this approach 2412 optional. 2414 Since a class encapsulates attributes, methods, and behavior, 2415 defining the Identification Object in the above example as a type 2416 of SUPAPolicyMetadata object enables the decorator pattern to be 2417 used to attach all or part of that object to other objects that 2418 need it. 2420 A 2421 +------------------+ 2422 | SUPAPolicyObject | 2423 +--------+---------+ 2424 / \ 0..n 2425 A 2426 \ / 2427 | A 2428 | 0..n +--------------------+ 2429 | SUPAHasPolicyMetadata \| | 2430 +-------------+-----------------+ SUPAPolicyMetadata | 2431 ^ /| | 2432 | +------+------+------+ 2433 C | / \ | 1..n 2434 +-------------+---------------+ I | 2435 0..n | | I | 2436 +----------+ SUPAHasPolicyMetadataDetail | I | 2437 | | | I | 2438 | +-----------------------------+ I | 2439 | I | 2440 | C I | 2441 | 0..n +----------------------------+ I | 2442 +----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+ | 2443 +----------------------------+ I | 2444 I | 2445 A I | 2446 +-----------------------------+ I | 2447 | SUPAPolicyMetadataDecorator +IIIIIIIII+ | 2448 +-------+--------------+------+ | 2449 / \ / \ 0..1 | 2450 I A | 2451 I \ / | 2452 I | | 2453 subclasses for adding | | 2454 behavior to policies +-----------------------+ 2455 and policy components SUPAHasMetadataDecorator 2457 Figure 17. SUPAPolicyMetadata Association Class Relationships 2459 Figure 18 shows a relevant portion of the SUPAPolicyMetadata 2460 hierarchy. SUPAPolicyConcreteMetadata is a concrete class that 2461 subclasses of the SUPAPolicyMetadataDecorator class can wrap. 2462 Two such subclasses, SUPAPolicyAccessMetadataDef and 2463 SUPAPolicyVersionMetadataDef, are shown in Figure 18. This 2464 enables access control and version information to be added 2465 statically (at design time) or dynamically (at runtime) to 2466 SUPAPolicyConcreteMetadata; this enables metadata-driven systems 2467 to adjust the behavior of the management system to changes in 2468 context, business rules, services given to end-users, and other 2469 similar factors. This is discussed more in sections 5.18 - 5.20. 2471 A 2472 +--------------------+ 2473 | | SUPAHasMetadataDecorator 2474 | SUPAPolicyMetadata +-------------------+ 2475 | | 1..n | 2476 +---------+----------+ | 2477 I | 2478 I | 2479 I | 2480 +-------------+-----------------+ | 2481 | | | 2482 C | | / \ 2483 +---------+------------------+ | A 2484 | SUPAPolicyConcreteMetadata | A | 0..1 \ / 2485 +----------------------------+ +--------+------------+-------+ 2486 | SUPAPolicyMetadataDecorator | 2487 +------------+----------------+ 2488 I 2489 +------------------------------+--------+ 2490 I I 2491 I I 2492 C I C I 2493 +---------------+-------------+ +---------------------+--------+ 2494 | SUPAPolicyAccessMetadataDef | | SUPAPolicyVersionMetadataDef | 2495 +-----------------------------+ +------------------------------+ 2497 Figure 18. SUPAPolicyMetadata Subclasses and Relationships 2499 5. GPIM Model 2500 This section defines the classes, attributes, and relationships of 2501 the GPIM. 2503 5.1. Overview 2504 The overall class hierarchy is shown in Figure 19. 2506 (Class of another model that SUPA is integrating into) 2507 | 2508 +---SUPAPolicyObject (Sec 5.2) 2509 | 2510 +---SUPAPolicyStructure (Sec 5.3) 2511 | 2512 +---SUPAPolicyComponentStructure (Sec 5.4) 2513 | | 2514 | +---SUPAPolicyClause (Sec 5.5) 2515 | | | 2516 | | +---SUPAEncodedClause (Sec 5.6) 2517 | | 2518 | +---SUPAPolicyClauseComponentDecorator (Sec 5.7) 2519 | | 2520 | +---SUPAPolicyTerm (Sec 5.8) 2521 | | | 2522 | | +---SUPAPolicyVariable (Sec 5.9) 2523 | | | 2524 | | +---SUPAPolicyOperator (Sec 5.10) 2525 | | | 2526 | | +---SUPAPolicyValue (Sec 5.11) 2527 | | 2528 | +---SUPAGenericDecoratedComponent (Sec 5.12) 2529 | | 2530 | +---SUPAPolicyCollection (Sec 5.13) 2531 | | 2532 | +---SUPAPolicyComponentDecorator (Sec 5.14) 2533 | 2534 +---SUPAPolicySource (Sec 5.15) 2535 | 2536 +---SUPAPolicyTarget (Sec 5.16) 2538 (Class of another model that SUPAPolicyMetadata is integrating into) 2539 | 2540 +---SUPAPolicyMetadata (Sec 5.17) 2541 | 2542 +---SUPAPolicyConcreteMetadata (Sec 5.18) 2543 | 2544 +---SUPAPolicyMetadataDecorator (Sec 5.19) 2545 | 2546 +---SUPAPolicyAccessMetadataDef (Sec 5.20) 2547 | 2548 +---SUPAPolicyVersionMetadataDef (5.20) 2550 Figure 19. Main Classes of the GPIM 2552 SUPAPolicy is the root of the SUPA class hierarchy. For 2553 implementations, it is assumed that SUPAPolicy is subclassed from 2554 a class from another model. Note that SUPAPolicyMetadata MAY be 2555 subclassed from the same or (preferably) a different class in the 2556 external model. 2558 Classes, attributes, and relationships that are marked as 2559 "mandatory" MUST be part of a conformant implementation (i.e., a 2560 schema MUST contain these entities). This does not mean that these 2561 entities must be instantiated; rather it means that they must be 2562 able to be instantiated. Classes, attributes, and relationships 2563 that are marked as "optional" MAY be part of a conformant 2564 implementation. Note that the Single Responsibility Principle [14] 2565 mandates that subclasses should not change inherited attributes. 2567 Unless otherwise stated, all classes (and attributes) defined in 2568 this section were abstracted from DEN-ng [2]. 2570 5.2. The Abstract Class "SUPAPolicyObject" 2572 This is a mandatory abstract class. Figure 20 shows the 2573 SUPAPolicyObject class, and its four subclasses. 2575 A 0..n 0..n A 2576 +----------------+/ \ \+------------------+ 2577 |SUPAPolicyObject+ A --------------------------+SUPAPolicyMetadata| 2578 +--------+-------+\ / SUPAHasPolicyMetadata /+------------------+ 2579 / \ 2580 I 2581 I 2582 +-----------------+----------------+-----------+ 2583 I I I I 2584 A I I I I 2585 +--------+------------+ I I I 2586 | SUPAPolicyStructure | I I I 2587 +---------------------+ I I I 2588 A I I I 2589 +-----------------+------------+ I I 2590 | SUPAPolicyComponentStructure | I I 2591 +------------------------------+ I I 2592 C I I 2593 +---------+--------+ I 2594 | SUPAPolicyTarget | I 2595 +------------------+ I 2596 C I 2597 +----------+-------+ 2598 | SUPAPolicySource | 2599 +------------------+ 2601 Figure 20. SUPAPolicyObject and Its Subclasses 2603 This class is the root of the SUPA class hierarchy. It defines the 2604 common attributes and relationships that all SUPA subclasses 2605 inherit. 2607 A SUPAPolicyObject MAY be qualified by a set of zero or more 2608 SUPAPolicyMetadata objects. This is provided by the 2609 SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This 2610 enables the semantics of the SUPAPolicyObject to be more 2611 completely specified. 2613 5.2.1. SUPAPolicyObject Attributes 2615 This section defines the attributes of the SUPAPolicyObject class. 2616 These attributes are inherited by all subclasses of the GPIM 2617 except for the SUPAPolicyMetadata class, which is a sibling class. 2619 5.2.1.1. Object Identifiers 2621 This document defines two class attributes in SUPAPolicyObject, 2622 called supaPolObjIDContent and supaPolObjIDEncoding, that together 2623 define a unique object ID. This enables all class instances to be 2624 uniquely identified. 2626 One of the goals of SUPA is to be able to generate different data 2627 models that support different types of protocols and repositories. 2628 This means that the notion of an object ID must be generic. It is 2629 inappropriate to use data modeling concepts, such as keys, Globally 2630 Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs), 2631 Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names 2632 (FQPNs), Uniform Resource Identifiers (URIs), and other similar 2633 mechanisms, to define the structure of an information model. 2634 Therefore, a synthetic object ID is defined using these two class 2635 attributes. This can be used to facilitate mapping to different data 2636 model object schemes. 2638 The two attributes work together, with the supaPolObjIDContent 2639 attribute defining the content of the object ID and the 2640 supaPolObjIDEncoding attribute defining how to interpret the 2641 content. These two attributes form a tuple, and together enable 2642 a machine to understand the syntax and value of an object 2643 identifier for the object instance of this class. 2645 Similarly, all SUPA classes are attributes are both uniquely 2646 named as well as prepended with the prefixes "SUPA" and "supa", 2647 respectively, to facilitate model integration. 2649 5.2.1.2. The Attribute "supaPolObjIDContent" 2651 This is a mandatory string attribute that represents part of the 2652 object identifier of an instance of this class. It defines the 2653 content of the object identifier. It works with another class 2654 attribute, called supaPolObjIDEncoding, which defines how to 2655 interpret this attribute. These two attributes form a tuple, 2656 and together enable a machine to understand the syntax and value 2657 of an object identifier for the object instance of this class. 2658 This is based on the DEN-ng class design [2]. 2660 5.2.1.3. The Attribute "supaPolObjIDEncoding" 2662 This is a mandatory non-zero enumerated integer attribute that 2663 represents part of the object identifier of an instance of this 2664 class. It defines the format of the object identifier. It works 2665 with another class attribute, called supaPolObjIDContent, which 2666 defines the content of the object ID. These two attributes form 2667 a tuple, and together enable a machine to understand the syntax 2668 and value of an object identifier for the object instance of 2669 this class. The supaPolObjIDEncoding attribute is mapped to the 2670 following values: 2672 0: error 2673 1: init 2674 2: primary_key 2675 3: foreign_key 2676 4: GUID 2677 5: UUID 2678 6: URI 2679 7: FQDN 2680 8: FQPN 2681 9: string_instance_id 2683 The values 0 and 1 represent an error state and an initialization 2684 state, respectively. The value 9 defines the canonical 2685 representation, in ASCII, of an instance ID of this object. 2687 5.2.1.4. The Attribute "supaPolicyDescription" 2689 This is an optional string attribute that defines a free-form 2690 textual description of this object. 2692 5.2.1.5. The Attribute "supaPolicyName" 2694 This is an optional string attribute that defines the name of this 2695 Policy. This enables any existing generic naming attribute to be 2696 used for generic naming, while allowing this attribute to be used 2697 to name Policy entities in a common manner. Note that this is NOT 2698 the same as the commonName attribute of the Policy class defined 2699 in [RFC3060], as that attribute is intended to be used with just 2700 X.500 cn attributes. 2702 5.2.2. SUPAPolicyObject Relationships 2704 The SUPAPolicyObject class currently defines a single relationship, 2705 as defined in the subsection below. 2707 5.2.2.1. The Aggregation "SUPAHasPolicyMetadata" 2709 This is a mandatory aggregation that defines the set of 2710 SUPAPolicyMetadata that are aggregated by this particular 2711 SUPAPolicyObject. This aggregation is defined in section 2712 5.16.2. 2714 5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail" 2716 This is a mandatory concrete association class that defines the 2717 semantics of the SUPAPolicyMetadata aggregation. This enables the 2718 attributes and relationships of the SUPAPolicyMetadataDetail class 2719 to be used to constrain which SUPAPolicyMetadata objects can be 2720 aggregated by this particular SUPAPolicyObject instance. This 2721 association class is defined in Section 5.16.2.2. 2723 5.3. The Abstract Class "SUPAPolicyStructure" 2725 This is a mandatory abstract class that is used to represent the 2726 structure of a SUPAPolicy. This class (and all of its subclasses) 2727 is a type of PolicyContainer. SUPAPolicyStructure was abstracted 2728 from DEN-ng [2], and a version of this class is in the process of 2729 being added to [5]. However, the version in [5] differs 2730 significantly. First, the class and relationship definitions ared 2731 different. Second, [5] uses the composite pattern. Neither of 2732 these are implemented in this document because of optimizations 2733 done to the SUPA class hierarchy that are NOT present in [5]. 2735 For this release, the only official type of policy that is 2736 supported is the event-condition-action (ECA) type of policy rule. 2737 However, the structure of the SUPA hierarchy is defined to 2738 facilitate adding new types of rules later. 2740 A SUPAPolicy may take the form of an individual policy or a set 2741 of policies. This requirement is supported by applying the 2742 composite pattern to subclasses of the SUPAPolicyStructure class, 2743 as shown in Figure 8. In this document, this is done for the 2744 SUPAECAPolicyRule subclass, and results in two subclasses: 2745 SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and 2746 SUPAECAPolicyRuleComposite (for defining hierarchies of policies). 2748 Note that there is no need for a "match strategy attribute" that 2749 some models [RFC3460], [4], [6] have; this is because the 2750 SUPAPolicyStructure class is used just for containment. Hence, the 2751 containers themselves serve as the scoping component for nested 2752 policies. 2754 5.3.1. SUPAPolicyStructure Attributes 2756 The following subsections define the attributes of the 2757 SUPAPolicyStructure class. 2759 The SUPAPolicyStructure class has a number of attributes that have 2760 no counterpart in the SUPAPolicyComponentStructure class. This is 2761 because these attributes are only appropriate at the level of a 2762 policy rule, not at the level of a policy component. 2764 Care must be taken in adding attributes to this class, 2765 because the behavior of future subclasses of this class (e.g., 2766 declarative and functional policies) is very different than the 2767 behavior of SUPAECAPolicyRules. 2769 5.3.1.1. The Attribute "supaPolAdminStatus" 2771 This is an optional attribute, which is an enumerated non-negative 2772 integer. It defines the current administrative status of this 2773 SUPAPolicyClause. Values include: 2775 0: error 2776 1: init 2777 2: enabled 2778 3: disabled 2779 4: in test (i.e., no operational traffic can be passed) 2781 The values 0 and 1 represent an error state and an initialization 2782 state, respectively. Values 2 and 3 mean that this 2783 SUPAPolicyStructure is administratively enabled or disabled, 2784 respectively. A value of 4 means that this SUPAPolicyStructure is 2785 currently in a special test mode and SHOULD NOT be used as part of 2786 an OAM&P policy. 2788 5.3.1.2. The Attribute "supaPolContinuumLevel" 2790 This is an optional non-negative integer attribute. It defines 2791 the level of abstraction, or policy continuum level [10], of this 2792 particular SUPAPolicy. The value assignment of this class is 2793 dependent on the application; however, it is recommended that 2794 for consistency with other SUPA attributes, the values of 0 and 1 2795 are reserved for error and initialization states. 2797 By convention, lower values represent more abstract levels of the 2798 policy continuum. For example, a value of 1 could represent 2799 business policy, a value of 2 could represent application-specific 2800 policies, and a value of 3 could represent low=level policies for 2801 network administrators. 2803 5.3.1.3. The Attribute "supaPolDeployStatus" 2805 This is an optional enumerated, non-negative integer attribute. The 2806 purpose of this attribute is to indicate that this SUPAPolicy can 2807 or cannot be deployed by the policy management system. This 2808 attribute enables the policy manager to know which SUPAPolicies to 2809 retrieve, and may be useful for the policy execution system for 2810 planning the staging of SUPAPolicies. Values include: 2812 0: error 2813 1: init 2814 2: deployed and enabled 2815 3: deployed and in test 2816 4: deployed but not enabled 2817 5: ready to be deployed 2818 6: cannot be deployed 2820 The values 0 and 1 represent an error state and an initialization 2821 state, respectively. A value of 2 means that the policy management 2822 system MAY use this SUPAPolicy. A value of 3-5 means that the 2823 policy management system SHOULD NOT use this SUPAPolicy until it is 2824 put into an enabled state. 2826 5.3.1.4. The Attribute "supaPolExecFailStrategy" 2828 This is an optional non-negative, enumerated integer that defines 2829 what actions, if any, should be taken by this 2830 SUPAPolicyStructure object if it fails to execute correctly. 2832 Note that some systems may not be able to support all options 2833 specified in this enumeration. If rollback is supported by the 2834 system, then option 2 may be skipped. Options 3 and 4 can be used 2835 by systems that do and do not support rollback. Values include: 2837 0: error 2838 1: init 2839 2: attempt rollback of all actions taken and stop execution 2840 3: attempt rollback of only the action that failed and stop 2841 execution 2842 4: stop execution but do not rollback any actions 2843 5: ignore failure and continue execution 2845 The values 0 and 1 represent an error state and an initialization 2846 state, respectively. A value of 2 means that ALL execution is 2847 stopped, rollback of all actions (whether successful or not) is 2848 attempted, and that SUPAPolicies that otherwise would have been 2849 executed are ignored. A value of 3 means that execution is stopped, 2850 and rollback is attempted for ONLY the SUPAPolicy that failed to 2851 execute correctly. A value of 4 means that execution is stopped, but 2852 no actions are rolled back. A value of 5 means that the failure is 2853 ignored, and execution continues. 2855 5.3.2. SUPAPolicyStructure Relationships 2857 The SUPAPolicyStructure class owns four relationships, which are 2858 defined in the following subsections. It also inherits the 2859 SUPAHasPolicyMetadata aggregation (see section 5.17.2.1.). 2861 5.3.2.1. The Aggregation "SUPAHasPolicySource" 2863 This is an optional aggregation, and defines the set of 2864 SUPAPolicySource objects that are attached to this particular 2865 SUPAPolicyStructure object. The semantics of this aggregation 2866 are defined by the SUPAHasPolicySourceDetail association class. 2867 PolicySource objects are used for authorization policies, as well 2868 as to enforce deontic and alethic logic. 2870 The multiplicity of this aggregation is 0..n - 0..n. This means 2871 that it is an optional aggregation; zero or more SUPAPolicySource 2872 objects may be aggregated by this SUPAPolicyStructure object, 2873 and zero or more SUPAPolicyStructure objects may aggregate this 2874 particular SUPAPolicySource object. 2876 5.3.2.2. The Association Class "SUPAHasPolicySourceDetail" 2878 This is an optional concrete association class, and defines the 2879 semantics of the SUPAHasPolicySource aggregation. The attributes and 2880 relationships of this class can be used to define which 2881 SUPAPolicySource objects can be attached to which particular set 2882 of SUPAPolicyStructure objects. 2884 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" 2886 This is an optional Boolean attribute. If the value of this 2887 attribute is true, then this SUPAPolicySource object has been 2888 authenticated by this particular SUPAPolicyStructure object. 2890 5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" 2892 This is an optional Boolean attribute. If the value of this 2893 attribute is TRUE, then this particular SUPAPolicySource object 2894 has been verified to be trusted by this particular 2895 SUPAPolicyStructure object. 2897 5.3.2.3. The Aggregation "SUPAHasPolicyTarget" 2899 This is an optional aggregation, and defines the set of 2900 SUPAPolicyTargets that are attached to this particular 2901 SUPAPolicyStructure. The semantics of this aggregation is 2902 defined by the SUPAHasPolicyTargetDetail association class. The 2903 purpose of this class is to explicitly identify managed objects 2904 that will be affected by the execution of one or more SUPAPolicies. 2906 The multiplicity of this aggregation is 0..n - 0..n. This means 2907 that it is an optional aggregation; zero or more SUPAPolicyTarget 2908 objects may be aggregated by this SUPAPolicyStructure object, 2909 and zero or more SUPAPolicyStructure objects may aggregate this 2910 particular SUPAPolicyTarget object. 2912 5.3.2.4. The Association Class "SUPAHasPolicyTargetDetail" 2914 This is an optional concrete association class, and defines the 2915 semantics of the SUPAPolicyTargetOf aggregation. The attributes and 2916 relationships of this class can be used to define which 2917 SUPAPolicyTargets can be attached to which particular set of 2918 SUPAPolicyStructure objects. 2920 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" 2922 This is an optional Boolean attribute. If the value of this 2923 attribute is true, then this SUPAPolicyTarget object has been 2924 authenticated by this particular SUPAPolicyStructure object. 2926 5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" 2928 This is an optional Boolean attribute. If its value is TRUE, then 2929 this SUPAPolicyTarget is able to be used as a SUPAPolicyTarget. 2930 This means that it meets two specific criteria: 2932 1. it has agreed to play the role of a SUPAPolicyTarget (i.e., 2933 it is willing to have SUPAPolicies applied to it, and 2934 2. it is able to either process (directly or with the aid of 2935 a proxy) SUPAPolicies or receive the results of a processed 2936 SUPAPolicy and apply those results to itself. 2938 5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" 2940 This is an optional association that defines which, if any, actions 2941 should be taken if this SUPAPolicyStructure object instance fails 2942 to execute correctly. The semantics of this association are defined 2943 in the SUPAHasPolExecFailTakeActionDetail association class. 2945 For a given SUPAPolicyStructure object A, this association defines 2946 a set of policy action objects B to execute if (and only if) the 2947 SUPAPolicyStructure object A failed to execute correctly. The 2948 multiplicity of this association is defined as 0..n on the owner 2949 (A) side and 1..n on the part (B) side. This means that this 2950 association is optional; if it is instantiated, then at least one 2951 SUPAPolicyStructure MUST be instantiated by this 2952 SUPAPolicyStructure object. Similarly, one or more 2953 SUPAPolicyStructure objects may be associated with this given 2954 SUPAPolicyStructure object. 2956 5.3.2.6. The Association Class "SUPAHasPolExecFailTakeActionDetail" 2958 This is an optional concrete class that defines the semantics for 2959 the SUPAHasPolExecFailTakeAction association. The attributes and/or 2960 relationships of this association class can be used to determine 2961 which policy action objects are executed in response to a failure 2962 of the SUPAPolicyStructure object instance that owns this 2963 association. The association defines the set of policy actions from 2964 one SUPAPolicyStructure object to be executed if another 2965 SUPAPolicyStructure object fails to execute properly. Figure 21 2966 illustrates this approach. 2968 A 2969 +---------------------------+ 0..n 2970 | +---------------------------------+ 2971 | | SUPAHasPolExecFailTakeAction | 2972 | SUPAPolicyStructure |/ | 2973 | + --------------+-----------------+ 2974 | |\ ^ 2975 +---------------------------+ 1..n | 2976 | 2977 C | 2978 +------------------+-----------------+ 2979 | SUPAHasPolExecFailTakeActionDetail | 2980 +------------------------------------+ 2982 Figure 21. SUPAHasPolExecFailTakeAction Association 2984 5.3.2.6.1. The Attribute "supaPolExecFailActionEncoding" 2986 This is an optional enumerated, non-negative integer attribute 2987 that defines how to find the set of SUPAPolicyActions contained 2988 in each element of the supaPolExecFailTakeActionName class 2989 attribute. Values include: 2991 0: error 2992 1: init 2993 2: URI 2994 3: GUID 2995 4: UUID 2996 5: FQDN 2997 6: FQPN 2998 7: string 2999 8: string_instance_id 3001 The values 0 and 1 represent an error state and an initialization 3002 state, respectively. Values 2-6 define a representation for the 3003 SUPAPolicyAction. A value of 7 defines an ASCII string that 3004 contains the name of the SUPAPolicyAction to be executed (e.g., to 3005 be used in a regex search). A value of 8 defines the canonical 3006 representation, in ASCII, of an instance ID of this object. 3008 5.3.2.6.2. The Attribute "supaPolExecFailActionName[1..n]" 3010 This is an optional array of string attributes that identifies the 3011 set of SUPAPolicyActions to take if the SUPAPolicyStructure object 3012 that owns this association failed to execute properly. The 3013 interpretation of this string attribute is defined by the 3014 supaPolExecFailTakeActionEncoding class attribute. The association 3015 defines the SUPAPolicyStructure that contains the set of policy 3016 actions to execute, and this attribute defines which of these 3017 actions are to be executed. That there is no need to execute a 3018 SUPAPolicy, since the event and failure have already occurred. 3019 Note: [1..n] means that this is a multi-valued property that has 3020 at least one (and possibly more) attributes. 3022 5.3.2.7. The Aggregation "SUPAHasPolicyClause" 3024 This is an optional aggregation that defines the set of 3025 SUPAPolicyClauses that are aggregated by this particular 3026 SUPAPolicyStructure instance. The semantics of this 3027 aggregation are defined by the SUPAHasPolicyClauseDetail 3028 association class. 3030 Every SUPAPolicyStructure object instance MUST aggregate at 3031 least one SUPAPolicyClause object instance. However, the 3032 converse is NOT true. For example, a SUPAPolicyClause could be 3033 instantiated and then stored for later use in a policy repository. 3034 Furthermore, the same SUPAPolicyClause could be used by zero or 3035 more SUPAPolicyStructure object instances at a given time. Thus, 3036 the multiplicity of this aggregation is defined as 0..1 on the 3037 aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the 3038 part (i.e., the SUPAPolicyClause side). This means that at 3039 least one SUPAPolicyClause MUST be aggregated by this 3040 SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may 3041 be aggregated by this particular SUPAPolicyStructure object. 3043 5.3.2.8. The Association Class "SUPAHasPolicyClauseDetail" 3045 This is an optional abstract association class, and defines the 3046 semantics of the SUPAHasPolicyClause aggregation. The attributes 3047 and/or relationships of this association class can be used to 3048 determine which SUPAPolicyClauses are aggregated by which 3049 SUPAPolicyStructure objects. 3051 5.4. The Abstract Class "SUPAPolicyComponentStructure" 3053 This is a mandatory abstract class. It is the superclass of all 3054 objects that represent different types of components of a 3055 SUPAPolicy. Different types of policies have different types of 3056 structural components. This is accommodated by defining two generic 3057 abstract subclasses, called SUPAPolicyClause and 3058 SUPAPolicyClauseComponentDecorator, which are both common to 3059 different policy types. These two classes represent convenient 3060 control points for defining characteristics and behavior that are 3061 common to objects that serve as components of a SUPAPolicy. 3063 SUPAPolicyClause defines a basic building block for writing 3064 parts of a SUPAPolicy. It is analogous to a clause in a sentence. 3065 For example, in an ECA Policy Rule, the Event, Condition, and Action 3066 clauses are each made up of at least one (concrete subclass of a) 3067 SUPAPolicyClause. Similalry, declarative Policy Rules can also be 3068 defined using (its own subclasses of) SUPAPolicyClauses. This class 3069 is defined in section 5.5. 3071 SUPAPolicyClauseComponentDecorator implements the decorator 3072 pattern [11]. The decorator pattern enables all or part of one or 3073 more objects to "wrap" another concrete object (as described in 3074 Section 4.2.1.2). This enables the definition of an extensible set 3075 of subclasses that can augment the definition of a SUPAPolicyClause. 3076 This class is defined in section 5.7. 3078 Note that there are significant differences between the definition 3079 of the SUPAPolicyComponentStructure class, and its attributes and 3080 relationships, and the definition of the corresponding class (and 3081 its attributes and relationships) in [5]. 3083 5.4.1. SUPAPolicyComponentStructure Attributes 3085 No attributes are currently defined for this class. 3087 5.4.2. SUPAPolicyComponentStructure Relationships 3089 SUPAPolicyComponentStructure participates in a single relationship, 3090 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. It 3091 also inherits the SUPAHasPolicyMetadata aggregation 3092 (see section 5.17.2.1.). 3094 5.5. The Abstract Class "SUPAPolicyClause" 3096 This is a mandatory abstract class that separates the 3097 representation of a SUPAPolicy from its implementation. 3098 SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction 3099 is missing in [RFC3060], [RFC3460], [4], and [6]. This class is 3100 called PolicyStatement in [5], but the class and relationship 3101 definitions differ significantly from the corresponding designs 3102 in this document. 3104 A SUPAPolicy, regardless of its structure and semantics, can be 3105 abstracted into a set of sentences. Each sentence can in turn be 3106 abstracted into a set of clauses. A SUPAPolicyClause is, as its 3107 name implies, a clause (i.e., a part of a statement), and defines 3108 the content of a SUPAPolicy. The decorator pattern is used to 3109 enable an extensible set of objects to "wrap" the SUPAPolicyClause; 3110 this enables the contents of a SUPAPolicyClause to be adjusted 3111 dynamically at runtime without affecting other objects. 3113 This document defines two different types of policy clauses: 3114 SUPAEncodedClause (which is generic, and can be used by any 3115 type of policy), and SUPABooleanClause (which is also generic, 3116 but is typically used by SUPAECAPolicyRule objects, since it is 3117 used specifically to represent Boolean clauses). 3119 SUPAPolicyClauses are objects in their own right, which 3120 facilitates their reuse. SUPAPolicyClauses can aggregate a set 3121 of any of the subclasses of SUPAPolicyClauseComponentDecorator; this 3122 was shown in Figures 12 and 13. These five subclasses (i.e., 3123 SUPAPolicyTerm, SUPAGenericDecoratedComponent, SUPAECAComponent, 3124 SUPACollection, and SUPAPolicyComponentDecorator) provide several 3125 different ways to construct a SUPAPolicyClause: 3127 1) a SUPAPolicyClause can be made up of a set of three 3128 SUPAPolicyTerms, which enables constructing an expression 3129 consiting of a {variable, operator, value} 3-tuple, for 3130 building SUPAPolicyClauses 3131 2) a SUPAPolicyClause can be made up of one or more 3132 SUPAEncodedClauses, which enables a SUPAPolicyClause to be 3133 formed as an encoded object (e.g., to pass YANG or CLI code) 3134 3) a SUPAPolicyClause can be made up of a set of SUPACollections, 3135 which define a Collection (e.g., set, bad, associative arrays) 3136 of objects that can be assembled into SUPAPolicyClauses after 3137 further processing 3138 4) a SUPAPolicyClause can be made up of one or more 3139 SUPAECAComponents, which enables a SUPAPolicyClause to be 3140 formed using (reusable) Event, Condition, and/or Action objects 3141 5) any or all of the above methods can be augmented with more 3142 complex decorated structures using SUPAPolicyComponentDecorator 3144 SUPAPolicyClauses are formed by aggregating a set of concrete 3145 subclasses of the SUPAPolicyClauseComponentDecorator class using the 3146 SUPAPolicyClauseHasDecorator aggregation (see Figure 12). The 3147 resulting SUPAPolicyClause is then aggregated by a concrete 3148 subclass of the SUPAPolicyStructure class, which enables a 3149 SUPAPolicy to be made up of one or more SUPAPolicyClauses. 3151 5.5.1. SUPAPolicyClause Attributes 3153 This section defines the attributes of the SUPAPolicyClause 3154 class, which are inherited by all SUPAPolicyClause subclasses. 3156 5.5.1.1. The Attribute "supaPolClauseDeployStatus" 3158 This is an optional enumerated, non-negative integer attribute. The 3159 purpose of this attribute is to indicate that this SUPAPolicyClause 3160 can or cannot be deployed by the policy management system. This 3161 attribute enables the policy manager to know which SUPAPolicyClauses 3162 to retrieve, and may be useful for the policy execution system for 3163 planning the staging of SUPAPolicies. Values include: 3165 0: error 3166 1: init 3167 2: deployed and enabled 3168 3: deployed and in test 3169 4: deployed but not enabled 3170 5: ready to be deployed 3171 6: cannot be deployed 3173 The values 0 and 1 represent an error state and an initialization 3174 state, respectively. If the value of this attribute is 0 or 6, then 3175 the policy management system SHOULD ignore this SUPAPolicy. 3176 Otherwise, the policy management system MAY use this SUPAPolicyClause 3177 (once this SUPAPolicyClause is deployed and enabled). However, a 3178 value of 4 means that this policy is not admininstratively enabled 3179 for use and SHOULD NOT be used in OAM&P policies. 3181 5.5.2. SUPAPolicyClause Relationships 3183 SUPAPolicyClause participates in two relationships. The first, 3184 SUPAHasPolicyClause, was defined in section 5.3.2.7. The second, 3185 SUPAPolicyClauseHasDecorator, is defined below. Note that 3186 SUPAPolicyClause uses the SUPAPolicyClauseHasDecorator aggregation 3187 to implement the decorator pattern; this enables a SUPAPolicyClause 3188 to be "wrapped" with instances of the (concrete) subclasses of the 3189 SUPAPolicyClauseComponentDecorator object. 3191 5.5.2.1. The Aggregation "SUPAPolicyClauseHasDecorator" 3193 This is a mandatory aggregation, and is part of a decorator 3194 pattern. It is used to enable a concrete instance of a 3195 SUPAPolicyClauseComponentDecorator to dynamically add behavior to a 3196 specific type (of concrete subclass) of a SUPAPolicyClause object. 3197 The semantics of this aggregation are defined by the 3198 SUPAPolicyClauseHasDecoratorDetail association class. 3200 The multiplicity of this aggregation is 0..n - 0..n. This means 3201 that a SUPAPolicyClause does not have to be decorated; however, if 3202 it is, then zero or more concrete subclasses of the 3203 SUPAPolicyClauseComponentDecorator class may be used to decorate 3204 the concrete subclass of SUPAPolicyClause. 3206 5.5.2.2. The Association Class "SUPAPolicyClauseHasDecoratorDetail" 3208 This is a mandatory concrete association class, and defines the 3209 semantics of the SUPAPolicyClauseHasDecorator aggregation. The 3210 purpose of this class is to use the Decorator pattern to determine 3211 which SUPAPolicyClauseComponentDecorator object instances, if any, 3212 are required to augment the functionality of the concrete subclass 3213 of the SUPAPolicyClause that is being used. 3215 Currently, there are two attributes defined for this class, which 3216 are described in the following subsections. Both attributes are 3217 used in this association class to **constrain the relationship** 3218 between the concrete subclass of SUPAPolicyClauseComponentDecorator 3219 that is wrapping the concrete subclass of SUPAPolicyClause. Note 3220 that class attributes of SUPAPolicyClauseComponentDecorator (see 3221 section 5.9.2) only affect that specific subclass. 3223 5.5.2.2.1. The Attribute "supaPolClauseDecConstraintEncoding" 3225 This is a mandatory non-negative enumerated integer that defines 3226 how to interpret each string in the supaPolClauseDecConstraint 3227 class attribute. Values include: 3229 0: error 3230 1: init 3231 2: OCL 2.4 3232 3: OCL 2.x 3233 4: OCL 1.x 3234 5: QVT 1.2 - Relations Language 3235 6: QVT 1.2 - Operational language 3236 7: Alloy 3237 8: ASCII Text 3239 Enumerations 0 and 1 signify an error state and an initialization 3240 state, respectively. Enumerations 2-4 are dedicated to OCL (with 3241 OCL 2.4 being the latest version as of this writing). QVT defines a 3242 set of languages [20] (the two most powerful and useful are defined 3243 by enumerations 5 and 6). Alloy is a language for describing 3244 constraints, and uses a SAT solver to guarantee correctness [21]. 3245 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 3246 and hence, not verifiable), but is included for completeness. 3248 5.5.2.2.2. The Attribute "supaPolClauseDecConstraint[0..n]" 3250 This is a mandatory array of string attributes. Each attribute 3251 specifies a constraint to be applied using the encoding defined in 3252 the supaPolCompConstraintEncoding class attribute. This provides 3253 a more rigorous and flexible treatment of constraints than is 3254 possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that 3255 this is a multi-valued property that may have zero or 3256 more attributes. 3258 5.6. The Concrete Class "SUPAEncodedClause" 3260 This is a mandatory concrete class that refines the behavior of a 3261 SUPAPolicyClause. 3263 This class defines a generalized extension mechanism for 3264 representing SUPAPolicyClauses that have not been modeled with 3265 other SUPAPolicy objects. This class encodes the contents of the 3266 policy clause directly into the attributes of the SUPAEncodedClause. 3267 Hence, SUPAEncodedClause objects are reusable at the object level, 3268 whereas SUPABooleanClause clauses are reusable at the individual 3269 Boolean expression level. 3271 This class uses two of its attributes (supaEncodedClauseContent and 3272 supaEncodedClauseEncoding) for defining the content and type of 3273 encoding used in a given SUPAPolicyClause. The benefit of a 3274 SUPAEncodedClause is that it enables direct encoding of the text of 3275 the SUPAPolicyClause, without having the "overhead" of using other 3276 objects. However, note that while this method is efficient, it 3277 does not reuse other SUPAPolicy objects. Furthermore, its potential 3278 for reuse is reduced, as only SUPAPolicies that can use the exact 3279 encoding of this clause can reuse this object. 3281 5.6.1. SUPAEncodedClause Attributes 3283 This section defines the attributes of the SUPAEncodedClause class. 3284 Prescriptive and/or descriptive information about the usage of this 3285 SUPAEncodedClause may be provided by one or more SUPAPolicyMetadata 3286 objects, which are each attached to the object instance of this 3287 SUPAEncodedClause. 3289 5.6.1.1. The Attribute "supaEncodedClauseContent" 3291 This is a mandatory string attribute, and defines the content of 3292 this clause. It works with another class attribute, called 3293 supaEncodedClauseEncoding, which defines how to interpret the 3294 value of this attribute (e.g., as a string or reference). These 3295 two attributes form a tuple, and together enable a machine to 3296 understand the syntax and value of this object instance. 3298 5.6.1.2. The Attribute "supaEncodedClauseEncoding" 3300 This is a mandatory non-negative integer attribute, and defines 3301 how to interpret the value of the supaEncodedClauseContent. It 3302 works with another class attribute (supaEncodedClauseContent), 3303 which defines the content of the encoded clause. These two 3304 attributes form a tuple, and together enable a machine to 3305 understand the syntax and value of the encoded clause for the 3306 object instance of this class. This attribute is NOT required in 3307 all data model implementations. Values include: 3309 0: error (i.e., an error state) 3310 1: init (i.e., an initialization state) 3311 2: primary_key 3312 3: foreign_key 3313 4: GUID 3314 5: UUID 3315 6: URI 3316 7: FQDN 3317 8: FQPN 3318 9: string_instance_id 3320 The values 0 and 1 represent an error state and an initialization 3321 state, respectively. The value 9 defines the canonical 3322 representation, in ASCII, of an instance ID of this object. 3324 5.6.1.3. The Attribute "supaEncodedClauseLanguage" 3326 This is mandatory non-negative integer attribute, and defines 3327 the type of language used in this encoded clause. Values include: 3329 0: error 3330 1: init 3331 2: Text 3332 3: YANG 3333 4: XML 3334 5: TL1 3336 The values 0 and 1 represent an error state and an initialization 3337 state, respectively. 3339 5.6.1.4. The Attribute "supaEncodedClauseResponse" 3341 This is an optional Boolean attribute that emulates a Boolean 3342 response of this clause, so that it may be combined with other 3343 subclasses of the SUPAPolicyClause that provide a status as to 3344 their correctness and/or evaluation state. This enables this 3345 object to be used to construct more complex Boolean clauses. 3346 Note that this attribute does NOT have to be implemented by all 3347 data model implementations (e.g., [15]). 3349 5.6.2. SUPAEncodedClause Relationships 3351 SUPAPolicyClause participates in two inherited relationships. These 3352 are SUPAHasPolicyClause, as defined in section 5.3.2.7, and 3353 SUPAPolicyClauseHasDecorator, as defined in section 5.7.2. 3355 5.7. The Abstract Class "SUPAPolicyClauseComponentDecorator" 3357 This is a mandatory class, and is used to implement the decorator 3358 pattern. The decorator pattern enables all or part of one or more 3359 objects to "wrap" another concrete object. This means that any 3360 any concrete subclass of SUPAPolicyClause can be wrapped by any 3361 concrete subclass of SUPAPolicyClauseComponentDecorator, as shown in 3362 Figure 22 below. 3364 SUPAHasPolicyClause 3365 +----------------+----------------------------+ 3366 | ^ | 3367 | | | 3368 | C | | 3369 | +-------------+----------------------+ | 3370 | | SUPAPolicyClauseHasDecoratorDetail | | 3371 | +-------------+----------------------+ | 3372 | | 3373 | | 3374 / \ | 3375 A | 3376 A \ / 0..n A \ / 1..n 3377 +--------+-----------+ +---------------------------+--------+ 3378 | SUPAPolicyClause | | SUPAPolicyClauseComponentDecorator | 3379 +----------+---------+ +--------------+---------------------+ 3380 I I 3381 I I 3382 / \ / \ 3383 Concrete Subclasses, Concrete Subclasses 3384 (e.g., SUPAEncodedClause) (e.g., SUPAPolicyEvent) 3385 that are being wrapped that are the wrapping object(s) 3387 Figure 22. SUPAPolicyClauseComponentDecorator 3389 The SUPAHasPolicyClause aggregation enables one or more concrete 3390 subclasses of SUPAPolicyClauseComponentDecorator to wrap a concrete 3391 subclass of SUPAPolicyClause. Its semantics are defined by the 3392 SUPAPolicyClauseHasDecoratorDetail association class. 3394 5.7.1. SUPAPolicyClauseComponentDecorator Attributes 3396 Currently, there are two attributes defined for this class, which 3397 are described in the following subsections. Both attributes are 3398 used by subclasses to **constrain the behavior of that subclass**; 3399 they do **not** affect the relationship between the concrete 3400 subclass of SUPAPolicyClauseComponentDecorator that is wrapping 3401 the concrete subclass of SUPAPolicyClause. 3403 This is different than the use of similar attributes defined in 3404 the SUPAPolicyClauseHasDecoratorDetail association class. The 3405 attributes of SUPAPolicyClauseComponentDecorator are used to 3406 constrain the (concrete subclass of) SUPAPolicyClause that this 3407 SUPAPolicyClauseComponentDecorator is wrapping. In contrast, the 3408 attributes of SUPAPolicyClauseHasDecoratorDetail are used to 3409 define which concrete subclasses of SUPAPolicyClause can be wrapped 3410 by which concrete subclasses of SUPAPolicyClauseComponentDecorator. 3412 5.7.1.1. The Attribute "supaPolClauseConstraintEncoding" 3414 This is a mandatory non-negative enumerated integer that defines 3415 how to interpret each string in the supaPolCompConstraint class 3416 attribute. Values include: 3418 0: error 3419 1: init 3420 2: OCL 2.4 3421 3: OCL 2.x 3422 4: OCL 1.x 3423 5: QVT 1.2 - Relations Language 3424 6: QVT 1.2 - Operational language 3425 7: Alloy 3426 8: ASCII Text 3428 Enumerations 0 and 1 signify an error state and an initialization 3429 state, respectively. Enumerations 2-4 are dedicated to OCL (with 3430 OCL 2.4 being the latest version as of this writing). QVT defines a 3431 set of languages [20] (the two most powerful and useful are defined 3432 by enumerations 5 and 6). Alloy is a language for describing 3433 constraints, and uses a SAT solver to guarantee correctness [21]. 3434 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 3435 and hence, not verifiable), but is included for completeness. 3437 5.7.1.2. The Attribute "supaPolClauseConstraint[0..n]" 3439 This is a mandatory array of string attributes. Each attribute 3440 specifies a constraint to be applied using the encoding defined in 3441 the supaPolCompConstraintEncoding class attribute. This provides 3442 a more rigorous and flexible treatment of constraints than is 3443 possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that 3444 this is a multi-valued property that may have zero or 3445 more attributes. 3447 5.7.2. SUPAPolicyClauseComponentDecorator Relationships 3449 This class currently participates in two relationships. The first, 3450 SUPAPolicyClauseHasDecorator, was defined in Section 5.5.2. The 3451 second, SUPAHasDecoratedPolicyComponent, is defined in 3452 Section 5.14.2. 3454 5.7.3. Illustration of Constraints in the Decorator Pattern 3456 Figure 23 builds a simple SUPAPolicyClause that has both types 3457 of relationships, and illustrates how the different constraints 3458 defined in sections 5.7.2 (class attribute constraints) and section 3459 5.7.3 (relationship constraints) can be used. 3461 A A 3462 +----------------+ 0..1 +----------------------------------+ 3463 | | 1..n / \| | 3464 |SUPAPolicyClause+------+---- A +SUPAPolicyClauseComponentDecorator| 3465 | | ^ \ /| | 3466 +---------+------+ | +-----------+----------------------+ 3467 / \ | / \ 3468 I | I 3469 I | I 3470 C I | C I 3471 +--------+--------+ | +---------+---------+ 3472 |SUPAEncodedClause| | | SUPAPolicyEvent | 3473 +-----------------+ | +-------------------+ 3474 | 3475 C | 3476 +---------------+------------+ 3477 |SUPAPolicyHasDecoratorDetail| 3478 +----------------------------+ 3480 Figure 23. Constraints in the Decorator Pattern 3482 Figure 23 says that a SUPAPolicyClause, realized as a 3483 SUPAEncodedClause object, is wrapped by a 3484 SUPAPolicyClauseComponentDecorator, realized as a SUPAPolicyEvent 3485 object. The attributes in the SUPAPolicyClauseComponentDecorator 3486 object, which are inherited by the SUPAPolicyEvent object, are 3487 used to constrain the behavior of the SUPAPolicyEvent object. 3489 Put another way, the SUPAPolicyClauseHasDecorator aggregation 3490 enables a concrete subclass of SUPAPolicyClause to be decorated by 3491 concrete subclasses of SUPAPolicyClauseComponentDecorator. The 3492 decorator pattern is implemente by the 3493 SUPAHasDecoratedPolicyComponent aggregation. Hence, attributes in 3494 the SUPAHasDecoratedPolicyComponentDetail association class are used 3495 to contrain the behavior of the decorator (e.g., restricting which 3496 concrete subclasses of the SUPAPolicyComponentDecorator can be used 3497 as decorators). For example, the attributes in the 3498 SUPAPolicyClauseComponentDecorator class, when instantiated in an 3499 instance of a concrete subclass, could restrict which 3500 SUPAPolicyEvent objects are allowed to be used with which 3501 SUPAEncodedClause objects. 3503 5.8. The Abstract Class "SUPAPolicyTerm" 3505 This is a mandatory abstract class that is the parent of 3506 SUPAPolicy objects that can be used to define a standard way to 3507 test or set the value of a variable. It does this by defining a 3508 3-tuple, in the form {variable, operator, value}, where each 3509 element of the 3-tuple is defined by a concrete subclass of the 3510 appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator, 3511 and SUPAPolicyValue classes, respectively). For example, a 3512 generic test or set of the value of a variable is expressed as: 3514 {variable, operator, value}. 3516 For event and condition clauses, this is typically as written above 3517 (e.g., does variable = value); for action clauses, it is typically 3518 written as (e.g., SET var to 1). A 3519 class diagram is shown in Figure 24. 3521 A 3522 +----------------+ 3523 | SUPAPolicyTerm | 3524 +--------+-------+ 3525 / \ 3526 I 3527 I 3528 I 3529 +-----------------+---+--------------------+ 3530 I I I 3531 I I I 3532 C I C I C I 3533 +--------+---------+ +--------+---------+ +-------+-------+ 3534 |SUPAPolicyVariable| |SUPAPolicyOperator| |SUPAPolicyValue| 3535 +------------------+ +------------------+ +---------------+ 3537 Figure 24. SUPAPolicyTerm Class Hierarchy 3539 Note that generic test and set expressions do not have to only use 3540 objects that are subclasses of SUPAPolicyTerm. For example, the 3541 supaGenericDecoratedCompContent attribute of the 3542 SUPAGenericDecoratedComponent could be used as the variable (or the 3543 value) term of a get or set expression that is in the above form. 3545 Hence, the utility of the subclasses of SUPAPolicyTerm is in the 3546 ability of its subclasses to define a generic framework for 3547 implementing get and set expressions. This is in contrast to 3548 previous designs (e.g., [RFC3460] and [6]), which depended on 3549 defining a broad set of subclasses of PolicyVariable and 3550 PolicyValue. (Note that [4] does not have this generic capability). 3552 5.8.1. SUPAPolicyTerm Attributes 3554 Currently, SUPAPolicyTerm defines a single attribute, as described 3555 in the following subsection. Constraints on the subclasses of 3556 SUPAPolicyTerm can be applied in two different ways: 3558 1. use SUPAPolicyComponentDecorator attributes to constrain 3559 just that individual subclass, and/or 3560 2. use SUPAHasDecoratedPolicyComponentDetail association class 3561 attributes to constrain the relationship between the concrete 3562 subclass of SUPAPolicyClause and the concrete subclass of 3563 the SUPAPolicyTerm class; this determines which concrete 3564 subclasses of SUPAPolicyTerm can be used to construct this 3565 particular SUPAPolicyClause. 3567 5.8.1.1. The Attribute "supaPolTermIsNegated" 3569 This is a mandatory Boolean attribute. If the value of this 3570 attribute is true, then this particular SUPAPolicyTerm subclass 3571 (which represents a term) is negated; otherwise, it is not. 3573 5.8.2. SUPAPolicyTerm Relationships 3575 Currently, no dedicated relationships are defined for the 3576 SUPAPolicyTerm class (as there are in [RFC3460] and [6]) that 3577 aggregate policy variable and policy value objects into a policy 3578 rule). This is: 3580 1) to enable the subclasses of SUPAPolicyTerm to be used by 3581 other SUPAPolicyComponentDecorator objects, and 3582 2) because the decorator pattern replaces how such relationships 3583 were used in [RFC3460] and [6]. 3585 SUPAPolicyTerm, and its subclasses, inherit the 3586 SUPAPolicyClauseHasDecorator aggregation, which was defined in 3587 Section 5.5.2, as well as the SUPAHasDecoratedPolicyComponent 3588 aggregation, which was defined in section 5.7.3. 3590 5.9. The Concrete Class "SUPAPolicyVariable" 3592 This is a mandatory concrete class that defines information that 3593 forms a part of a SUPAPolicyClause. It specifies a concept or 3594 attribute that represents a variable, which should be compared to 3595 a value, as specifed in this SUPAPolicyClause. If it is used in 3596 a SUPAECAPolicyRule, then its value MAY be able to be changed at 3597 any time, including run-time, via use of the decorator pattern. 3598 This is not possible in previous designs ([RFC3460, [4], and [6]). 3600 The value of a SUPAPolicyVariable is typically compared to the 3601 value of a SUPAPolicyValue using the type of operator defined in 3602 a SUPAPolicyOperator. However, other objects may be used instead 3603 of a SUPAPolicyValue object, and other operators may be defined 3604 in addition to those defined in the SUPAPolicyOperator class. 3606 SUPAPolicyVariables are used to abstract the representation of a 3607 SUPAPolicyClause from its implementation. Some SUPAPolicyVariables 3608 are restricted in the values and/or the data type that they may 3609 be assigned. For example, port numbers cannot be negative, and 3610 they cannot be floating-point numbers. These and other constraints 3611 may be defined in two different ways: 3613 1. use SUPAPolicyClauseComponentDecorator attributes to constrain 3614 just that individual object, and/or 3615 2. use the SUPAPolicyClauseHasDecoratorDetail association class 3616 attributes to constrain the relationship between the concrete 3617 subclass of SUPAPolicyClause and the concrete subclass of 3618 the SUPAPolicyVariable class 3620 Please refer to the examples in section 7, which show how to 3621 restrict the value, data type, range, and other semantics of the 3622 SUPAPolicyVariable when used in a SUPAPolicyClause. 3624 5.9.1. Problems with the RFC3460 Version of PolicyValue 3626 Please see Appendix A for a detailed comparison. 3628 5.9.2. SUPAPolicyVariable Attributes 3630 SUPAPolicyVariable defines one attribute, as described below. 3632 5.9.2.1. The Attribute "supaPolVarName" 3634 This is an optional string attribute that contains the name of 3635 this SUPAPolicyVariable. This variable name forms part of the 3636 {variable, operator, value} canonical form of a SUPAPolicyClause. 3638 5.9.3. SUPAPolicyVariable Relationships 3640 Currently, no relationships are defined for the SUPAPolicyVariable 3641 class (note that the decorator pattern obviates the need for 3642 relationships such as those defined in [RFC3460] and [6]). This is 3643 because SUPAPolicyVariable, and its subclasses, inherit the 3644 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3645 section 5.7.3. 3647 5.10. The Concrete Class "SUPAPolicyOperator" 3649 This is a mandatory concrete class for modeling different types of 3650 operators that are used in a SUPAPolicyClause. 3652 The restriction of the type of operator used in a SUPAPolicyClause 3653 restricts the semantics that can be expressed in that 3654 SUPAPolicyClause. It is typically used with SUPAPolicyVariables 3655 and SUPAPolicyValues to form a SUPAPolicyClause. 3657 5.10.1. Problems with the RFC3460 Version 3659 Please see Appendix A for a detailed comparison. 3661 5.10.2. SUPAPolicyOperator Attributes 3663 Currently, SUPAPolicyOperator defines a single generic attribute, 3664 as described below. 3666 5.10.2.1. The Attribute "supaPolOpType" 3668 This is a mandatory non-negative enumerated integer that specifies 3669 the various types of operators that are allowed to be used in this 3670 particular SUPAPolicyClause. Values include: 3672 0: error 3673 1: init 3674 2: Greater than 3675 3: Greater than or equal to 3676 4: Less than 3677 5: Less than or equal to 3678 6: Equal to 3679 7: Not equal to 3680 8: IN 3681 9: NOT IN 3682 10: SET 3683 11: CLEAR (0 for integers, "" for strings, FALSE for Booleans) 3684 12: BETWEEN (inclusive) 3685 13: regular expression, PERL-based 3686 14: regular expression, POSIX-based (BRE, basic) 3687 15: regular expression, POSIX-based (ERE, extended) 3689 Note that 0 and 1 represent error and initialization states, 3690 respectively. Their purpose is to support dynamically building a 3691 SUPAPolicyClause by enabling the application to set the value of 3692 this attribute to a standard value. 3694 This list has been influenced by the work in the I2NSF WG. 3695 Specifically, references [22] and [23] categorize selectors as 3696 exact-match, range-based, regular expressions, and custom match. In 3697 this categorization, the values in the above enumeration are mapped 3698 as follows: 3700 o "Exact-match" is used to check for equality. The result is an 3701 unstructured unordered set. This includes values 6 and 7. 3702 o "Range-based" are **ordered** sets, where ranges that map to 3703 integers are used. This includes values 2-5, 8, 9, and 12. 3704 o "Regular expressions", which include the use of special 3705 characters that collectively define a search pattern. Two 3706 different syntaxes are specified; they are documented in [24] 3707 (for value 14) and [25]. This maps to values 13-15. 3709 Note that POSIX-based simple regular expressions (SRE) are 3710 **deprecated** by POSIX-based basic regular expressions (BRE). 3712 Additional operators may be defined in future work. For example, 3713 if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from 3714 include structured objects, then "deep" versions of operators 3715 1-6 could also be defined. In this case, values 1-6 will be 3716 edited to explicitly indicate that they perform "shallow" 3717 comparison operations. 3719 5.10.3. SUPAPolicyOperator Relationships 3721 Currently, no relationships are defined for the SUPAPolicyOperator 3722 class (note that the decorator pattern obviates the need for 3723 relationships such as those in [6]). This is because 3724 SUPAPolicyOperator, and its subclasses, inherit the 3725 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3726 section 5.7.3. Please refer to the examples in section 7, which 3727 show how to restrict the value, data type, range, and other 3728 semantics of the SUPAPolicyOperator when used in a SUPAPolicyClause. 3730 5.11. The Concrete Class "SUPAPolicyValue" 3732 The SUPAPolicyValue class is a mandatory concrete class for 3733 modeling different types of values and constants that occur in a 3734 SUPAPolicyClause. 3736 SUPAPolicyValues are used to abstract the representation of a 3737 SUPAPolicyRule from its implementation. Therefore, the design of 3738 SUPAPolicyValues depends on two important factors. 3740 First, just as with SUPAPolicyVariables (see Section 5.9), some 3741 types of SUPAPolicyValues are restricted in the values and/or the 3742 data type that they may be assigned. Second, there is a high 3743 likelihood that specific applications will need to use their own 3744 variables that have specific meaning to a particular application. 3746 In general, there are two ways to apply constraints to an object 3747 instance of a SUPAPolicyValue: 3749 1. use SUPAPolicyClauseComponentDecorator attributes to constrain 3750 just that individual object, and/or 3751 2. use the SUPAPolicyClauseHasDecoratorDetail association class 3752 attributes to constrain the relationship between the concrete 3753 subclass of SUPAPolicyClause and the concrete subclass of 3754 the SUPAPolicyVariable class 3756 The value of a SUPAPolicyValue is typically compared to the value 3757 of a SUPAPolicyVariable using the type of operator defined in 3758 a SUPAPolicyOperator. However, other objects may be used instead 3759 of a SUPAPolicyVariable object, and other operators may be defined 3760 in addition to those defined in the SUPAPolicyOperator class. 3762 Please refer to the examples in section 7, which show how to 3763 restrict the value, data type, range, and other semantics of the 3764 SUPAPolicyVariable when used in a SUPAPolicyClause. 3766 5.11.1. Problems with the RFC3460 Version of PolicyValue 3768 Please see Appendix A for a detailed comparison. 3770 5.11.2. SUPAPolicyValue Attributes 3772 Currently, SUPAPolicyValue defines two generic attributes, as 3773 described below. 3775 5.11.2.1. The Attribute "supaPolValContent[0..n]" 3777 This is a mandatory attribute that defines an array of strings. 3778 The array contains the value(s) of this SUPAPolicyValue object 3779 instance. Its data type is defined by the supaPolValEncoding 3780 class attribute. Note: [0..n] means that this is a multi-valued 3781 property that has zero or more attributes. 3783 5.11.2.2. The Attribute "supaPolValEncoding" 3785 This is a mandatory string attribute that contains the data type 3786 of the SUPAPolicyValue object instance. Its value is defined by 3787 the supaPolValContent class attribute. Values include: 3789 0: error 3790 1: init 3791 2: String 3792 3: Integer 3793 4: Boolean 3794 5: Floating Point 3795 6: DateTime 3796 7: GUID 3797 8: UUID 3798 9: URI 3799 10: DN 3800 11: FQDN 3801 12: FQPN 3802 13: NULL 3804 Note that 0 and 1 represent error and initialization states, 3805 respectively. A string is a sequence of zero or more characters. An 3806 Integer is a whole number, and has no fractional part. A Boolean may 3807 take the values TRUE and FALSE. A floating point number may contain 3808 fractional values, as well as an exponent. A DateTime represents a 3809 value that has a date and/or a time component (as in the Java or 3810 Python libraries). A NULL explicitly models the lack of a value. 3812 5.11.3. SUPAPolicyValue Relationships 3814 Currently, no relationships are defined for the SUPAPolicyValue 3815 class (note that the decorator pattern obviates the need for 3816 relationships such as those in [6]). SUPAPolicyValue, and its 3817 subclasses, inherit the SUPAHasDecoratedPolicyComponent 3818 aggregation, which was defined in section 5.7.3. Please refer to 3819 the examples in section 7, which show how to restrict the value, 3820 data type, range, and other semantics of the SUPAPolicyValue when 3821 used in a SUPAPolicyClause. 3823 5.12. The Concrete Class "SUPAGenericDecoratedComponent" 3825 A SUPAGenericDecoratedComponent enables a generic object to be 3826 defined and used in a SUPAPolicyClause. This class was derived 3827 from [2], but is not present in [RFC3460], [4], [5], or [6]. 3829 This class should not be confused with the SUPAEncodedClause class. 3830 The SUPAGenericDecoratedComponent class represents a single, atomic 3831 object that defines a **portion** of a SUPAPolicyClause, whereas a 3832 SUPAEncodedClause represents an **entire** SUPAPolicyClause. 3834 5.12.1. SUPAGenericDecoratedComponent Attributes 3836 Currently, SUPAGenericDecoratedComponent defines two generic 3837 attributes, as described below. 3839 5.12.1.1. The Attribute "supaGenericDecoratedCompContent[0..n]" 3841 This is a mandatory attribute that defines an array of strings. 3842 This array contains the value(s) of the 3843 SUPAGenericDecoratedComponent object instance that are used to 3844 construct a portion of a SUPAPolicyClause. Its data type is 3845 defined by the supaGenericDecoratedCompEncoding class attribute. 3846 Note: [0..n] means that this is a multi-valued property that has 3847 zero or more attributes. 3849 5.12.1.2. The Attribute "supaGenericDecoratedCompEncoding" 3851 This is a mandatory integer attribute that defines the format of 3852 the supaGenericDecoratedCompContent class attribute. Values include: 3854 0: error 3855 1: init 3856 2: String 3857 3: Integer 3858 4: Boolean 3859 5: Floating Point 3860 6: DateTime 3861 7: GUID 3862 8: UUID 3863 9: URI 3864 10: DN 3865 11: FQDN 3866 12: FQPN 3867 13: NULL 3869 Note that 0 and 1 represent error and initialization states, 3870 respectively. A string is a sequence of zero or more characters. An 3871 Integer is a whole number, and has no fractional part. A Boolean may 3872 take the values TRUE and FALSE. A floating point number may contain 3873 fractional values, as well as an exponent. A DateTime represents a 3874 value that has a date and/or a time component (as in the Java or 3875 Python libraries). A NULL explicitly models the lack of a value. 3877 5.12.2. SUPAGenericDecoratedComponent Relationships 3879 Currently, no relationships are defiend for the 3880 SUPAGenericDecoratedComponent class (note that the decorator 3881 pattern obviates the need for relationships such as those in [6]). 3882 SUPAGenericDecoratedComponent participates in a single relationship, 3883 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 3885 5.13. The Concrete Class "SUPAPolicyCollection" 3887 A SUPAPolicyCollection is an optional concrete class that enables 3888 a collection (e.g., set, bag, or other, more complex, collections 3889 of elements) of **arbitrary objects** to be defined and used as 3890 part of a SUPAPolicyClause. This class was derived from [2], but 3891 is not present in [RFC3460], [4], [5], or [6]. 3893 5.13.1. Motivation 3895 One of the problems with ECA policy rules is when an enumeration 3896 occurs in the event and/or condition clauses. For example, if a 3897 set of events is received, the policy system may need to wait for 3898 patterns of events to emerge (e.g., any number of Events of type A, 3899 followed by either one event of type B or two events of type 3900 Event C). Similarly, for conditions, testing the value of a set of 3901 attributes may need to be performed. Both of these represent 3902 behavior similar to a set of if-then-else statements or a switch 3903 statement in imperative programming languages. 3905 It is typically not desirable for the policy system to represent 3906 each choice in such clauses as its own policy clause (i.e., a 3907 3-tuple), as this creates object explosion and poor performance. 3908 Furthermore, in these cases, it is often required to have a set of 3909 complex logic to be executed, where the logic varies according to 3910 the particular event or condition that was selected. It is much 3911 too complex to represent this using separate objects, especially 3912 when the logic is application- and/or vendor-specific. However, 3913 recall that one of the goals of this document was to facilitate 3914 the machine-driven construction of policies. Therefore, a solution 3915 to this problem is needed. 3917 5.13.2. Solution 3919 Therefore, this document defines the concept of a collection of 3920 entities, called a SUPAPolicyCollection. Conceptually, the items 3921 to be collected (e.g., events or conditions) are aggregated in 3922 one or more SUPAPolicyCollection objects of the appropriate type. 3923 Another optional SUPAPolicyCollection object could be used to 3924 aggregate logic blocks (including SUPAPolicies) to execute. 3925 Once finished, all appropriate SUPAPolicyCollection objects are 3926 sent to an external system for evaluation. 3928 The computation(s) represented by the SUPAPolicyCollection may be 3929 part of a larger SUPAPolicyClause, since SUPAPolicyCollection is a 3930 subclass of SUPAPolicyComponentDecorator, and can be used to 3931 decorate a SUPAPolicyClause. Therefore, the external system is 3932 responsible for providing a Boolean TRUE or FALSE return value, so 3933 that the policy system can use that value to represent the 3934 computation of the function(s) performed in the 3935 SUPAPolicyCollection in a Boolean clause. 3937 5.13.3. SUPAPolicyCollection Attributes 3939 Currently, SUPAGenericDecoratedComponent defines five attributes, 3940 as described below. 3942 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 3944 This is an optional attribute that defines an array of strings. 3945 Each string in the array defines a domain-suitable identifier of 3946 an object that is collected by this SUPAPolicyCollection instance. 3947 Note: [0..n] means that this is a multi-valued property that has 3948 zero or more attributes. 3950 5.13.3.2. The Attribute "supaPolCollectionEncoding" 3952 This is a mandatory non-negative enumerated integer that defines 3953 the format of the identifier of all objects in this collection 3954 instance. Values include: 3956 0: error (i.e., an error state) 3957 1: init (i.e., an initialization state) 3958 2: primary_key 3959 3: foreign_key 3960 4: GUID 3961 5: UUID 3962 6: URI 3963 7: FQDN 3964 8: FQPN 3965 9: string_instance_id 3967 Note that 0 and 1 represent error and initialization states, 3968 respectively. Values 2-8 define the content as a reference. 3969 The value 9 defines the canonical representation, in ASCII, of 3970 an instance ID of this object. 3972 5.13.3.3. The Attribute "supaPolCollectionFunction" 3974 This is an optional non-negative enumerated integer that defines 3975 the function of this collection instance. Values include: 3977 0: error 3978 1: init 3979 2: event collection 3980 3: condition collection 3981 4: action collection 3982 5: processing logic collection 3984 Note that 0 and 1 represent error and initialization states, 3985 respectively. Values 2-4 define a collection of objects that are to 3986 be used to populate the event, condition, or action clauses, 3987 respectively, of a SUPAECAPolicyRule. A value of 5 indicates that 3988 this collection contains objects that define logic for processing 3989 a SUPAPolicy. 3991 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" 3993 This is an optional Boolean attribute. If the value of this 3994 attribute is TRUE, then all elements in this instance of this 3995 SUPAPolicyCollection are ordered. 3997 5.13.3.5. The Attribute "supaPolCollectionType" 3999 This is an optional non-negative enumerated integer that defines 4000 the type of collection that this instance is. Values include: 4002 0: error 4003 1: init 4004 2: set 4005 3: bag (e.g., multi-set) 4006 4: dictionary (e.g., associative array) 4008 Note that 0 and 1 represent error and initialization states, 4009 respectively. A set is an unordered collection of elements that MUST 4010 NOT have duplicates. A bag is an unordered collection of elements; 4011 it MAY have duplicates. A dictionary is a table that associates a 4012 key with a value. 4014 Sets have a number of important functions, including: 4016 o membership: returns TRUE if the element being tested is 4017 in the set, and FALSE otherwise 4018 o subset: returns TRUE if all elements in the first set 4019 are also in the second set 4020 o union: returns all elements from both sets with no 4021 duplicates 4022 o intersection: returns all elements that are in both sets 4023 with no duplicates 4024 o difference: returns all elements in the first set that 4025 are not in the second set 4027 Bags have a number of important functions in addition to the 4028 functions defined for sets (note that while the above set of 4029 functions for a set and a bag are the same, a bag is a different 4030 data type than a set): 4032 o multiplicity: returns the number of occurrences of an 4033 element in the bag 4035 o count: returns the number of all items, including 4036 duplicates 4037 o countDistinct: returns the number of items, where all 4038 duplicates are ignored 4040 A dictionary is an unordered set of key:value pairs, where each 4041 key is unique within a given dictionary. The combination of a 4042 key and a value is called an item. The format of an item is 4043 defined as one element (the key) followed by a colon followed 4044 by a second element (the value). Each item in a set of items is 4045 separated by a comma. Keys MUST NOT be NULL; values MAY be NULL. 4047 An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}. 4048 An example of a null dictionary is simply {}. 4050 5.13.4. SUPAPolicyCollection Relationships 4052 Currently, no relationships are defined for the 4053 SUPAGenericDecoratedComponent class (note that the decorator 4054 pattern obviates the need for relationships such as those in [6]). 4055 SUPAPolicyCollection participates in a single relationship, 4056 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 4058 5.14. The Abstract Class "SUPAPolicyComponentDecorator" 4060 This is an optional class, and represents how the decorator pattern 4061 can be applied to objects that decorate another object. This is 4062 shown in Figure 25 below. 4064 A 4065 +--------------+---------------------+ 4066 | |/ 4067 | SUPAPolicyClauseComponentDecorator +------------+ 4068 | |\ | 4069 +----------+-------------------------+ 0..n | 4070 | 4071 SUPAHasDecoratedPolicyComponent | 4072 +---------------------------------+ 4073 ^ | 4074 | | 4075 C | | 4076 +---------------+---------------------+ | 4077 |SUPAHasDecoratedPolicyComponentDetail| / \ 4078 +---------------+---------------------+ A 4079 A \ / 0..1 4080 +---------------+--------------+ 4081 | SUPAPolicyComponentDecorator | 4082 +------------------------------+ 4084 Figure 25. Decorating Objects that Decorate Another Object 4086 Figure 25 realizes a recursive decorator pattern, in that any 4087 concrete subclass of SUPAPolicyClauseComponentDecorator can be 4088 decorated by any concrete subclass of SUPAPolicyComponentDecorator. 4090 The SUPAHasPolicyClause aggregation enables one or more concrete 4091 subclasses of SUPAPolicyClauseComponentDecorator to wrap a concrete 4092 subclass of SUPAPolicyClause. Its semantics are defined by the 4093 SUPAPolicyClauseHasDecoratorDetail association class. 4095 5.14.1. SUPAPolicyComponentDecorator Attributes 4097 Currently, there are two attributes defined for this class, which 4098 are described in the following subsections. Both attributes are 4099 used by subclasses to **constrain the behavior of that subclass**; 4100 they do **not** affect the relationship between the concrete 4101 subclass of SUPAPolicyComponentDecorator that is wrapping 4102 the concrete subclass of SUPAPolicyClauseComponentDecorator. 4104 This is different than the use of similar attributes defined in 4105 the SUPAHasDecoratedPolicyComponentDetail association class. The 4106 attributes of SUPAPolicyComponentDecorator are used to constrain 4107 the (concrete subclass of) the SUPAPolicyClauseComponentDecorator 4108 that is being wrapped. In contrast, the attributes of 4109 SUPAHasDecoratedPolicyComponentDetail are used to define which 4110 concrete subclasses of SUPAPolicyClauseComponentDecorator can be 4111 wrapped by which concrete subclasses of the 4112 SUPAPolicyComponentDecorator class. 4114 5.14.1.1. The Attribute "supaPolCompConstraintEncoding" 4116 This is a mandatory non-negative enumerated integer that defines 4117 how to interpret each string in the supaPolCompConstraint class 4118 attribute. Values include: 4120 0: error 4121 1: init 4122 2: OCL 2.4 4123 3: OCL 2.x 4124 4: OCL 1.x 4125 5: QVT 1.2 - Relations Language 4126 6: QVT 1.2 - Operational language 4127 7: Alloy 4128 8: ASCII Text 4130 Enumerations 0 and 1 signify an error state and an initialization 4131 state, respectively. Enumerations 2-4 are dedicated to OCL (with 4132 OCL 2.4 being the latest version as of this writing). QVT defines a 4133 set of languages [20] (the two most powerful and useful are defined 4134 by enumerations 5 and 6). Alloy is a language for describing 4135 constraints, and uses a SAT solver to guarantee correctness [21]. 4136 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 4137 and hence, not verifiable), but is included for completeness. 4139 5.14.1.2. The Attribute "supaPolCompConstraint[0..n]" 4141 This is a mandatory array of string attributes. Each attribute 4142 specifies a constraint to be applied using the encoding defined in 4143 the supaPolCompConstraintEncoding class attribute. This provides 4144 a more rigorous and flexible treatment of constraints than is 4145 possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that 4146 this is a multi-valued property that may have zero or 4147 more attributes. 4149 5.14.2. SUPAPolicyComponentDecorator Relationships 4151 A single relationship is currently defined for the 4152 SUPAPolicyComponentDecorator, which is described below. 4154 5.14.2.1 The Aggregation "SUPAHasDecoratedPolicyComponent" 4156 This is a mandatory aggregation, and is part of a recursive 4157 decorator pattern. It is used to enable a concrete instance of a 4158 SUPAPolicyComponentDecorator to dynamically add behavior to a 4159 specific type (of concrete subclass) of a 4160 SUPAPolicyClauseComponentDecorator object. The semantics of this 4161 aggregation are defined by the SUPAHasDecoratedPolicyComponentDetail 4162 association class. 4164 5.14.2.2. The Association Class 4165 "SUPAHasDecoratedPolicyComponentDetail" 4167 This is a mandatory concrete association class, and defines the 4168 semantics of the SUPAHasDecoratedPolicyComponent aggregation. The 4169 purpose of this class is to use the Decorator pattern to determine 4170 which concrete subclasses of the SUPAPolicyComponentDecorator class, 4171 if any, are required to augment the functionality of the concrete 4172 subclass of SUPAPolicyClauseComponentDecorator that is being used. 4174 Currently, there are two attributes defined for this class, which 4175 are described in the following subsections. Both attributes are 4176 used in this association class to constrain the **relationship** 4177 between the concrete subclass of SUPAPolicyComponentDecorator that 4178 is wrapping the concrete subclass of the 4179 SUPAPolicyClauseComponentDecorator class. 4181 5.14.2.1.1. The Attribute "supaPolCompConstraintEncoding" 4183 This is a mandatory non-negative enumerated integer that defines 4184 how to interpret each string in the supaDecoratedConstraint class 4185 attribute. Values include: 4187 0: error 4188 1: init 4189 2: OCL 2.4 4190 3: OCL 2.x 4191 4: OCL 1.x 4192 5: QVT 1.2 - Relations Language 4193 6: QVT 1.2 - Operational language 4194 7: Alloy 4195 8: ASCII Text 4197 Enumerations 0 and 1 signify an error state and an initialization 4198 state, respectively. Enumerations 2-4 are dedicated to OCL (with 4199 OCL 2.4 being the latest version as of this writing). QVT defines a 4200 set of languages [20] (the two most powerful and useful are defined 4201 by enumerations 5 and 6). Alloy is a language for describing 4202 constraints, and uses a SAT solver to guarantee correctness [21]. 4203 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 4204 and hence, not verifiable), but is included for completeness. 4205 If this class is instantiated, then this attribute SHOULD also be 4206 instantiated, and SHOULD be part of a conformant implementation. 4208 5.14.2.1.2. The Attribute "supaPolCompConstraint[0..n]" 4210 This is a mandatory array of string attributes. Its purpose is to 4211 collect a set of constraints to be applied to a decorated object. 4212 The interpretation of each constraint in the array is defined in 4213 the supaDecoratedConstraintsEncoding class attribute. 4214 Note: [0..n] means that this is a multi-valued property that may 4215 have zero or more attributes. 4217 5.15. The Concrete Class "SUPAPolicySource" 4219 This is an optional class that defines a set of managed entities 4220 that authored, or are otherwise responsible for, this 4221 SUPAPolicyRule. Note that a SUPAPolicySource does NOT 4222 evaluate or execute SUPAPolicies. Its primary use is for 4223 auditability and the implementation of deontic and/or alethic logic. 4224 A class diagram is shown in Figure 15. 4226 A SUPAPolicySource SHOULD be mapped to a role or set of roles 4227 (e.g., using the role-object pattern [11]). This enables 4228 role-based access control to be used to restrict which entities 4229 can author a given policy. Note that Role is a type of 4230 SUPAPolicyMetadata. 4232 5.15.1. SUPAPolicySource Attributes 4234 Currently, no attributes are defined for this class. 4236 5.15.2. SUPAPolicySource Relationships 4238 SUPAPolicySource participates in a single relationship, 4239 SUPAHasPolicySource, as defined in section 5.3.2.1. 4240 SUPAPolicySource, and its subclasses, inherit the 4241 SUPAHasPolicyMetadata aggregation, which is 4242 defined in section 5.17.2.1. 4244 5.16. The Concrete Class "SUPAPolicyTarget" 4246 This is an optional class that defines a set of managed entities 4247 that a SUPAPolicy is applied to. Figure 15 shows a class diagram 4248 of the SUPAPolicyTarget. 4250 A managed object must satisfy two conditions in order to be defined 4251 as a SUPAPolicyTarget. First, the set of managed entities that are 4252 to be affected by the SUPAPolicy must all agree to play the role of 4253 a SUPAPolicyTarget. In general, a managed entity may or may not be 4254 in a state that enables SUPAPolicies to be applied to it to change 4255 its state; hence, a negotiation process may need to occur to enable 4256 the SUPAPolicyTarget to signal when it is willing to have 4257 SUPAPolicies applied to it. Second, a SUPAPolicyTarget must be able 4258 to process (directly or with the aid of a proxy) SUPAPolicies. 4260 If a proposed SUPAPolicyTarget meets both of these conditions, it 4261 SHOULD set its supaPolicyTargetEnabled Boolean attribute to a 4262 value of TRUE. 4264 A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the 4265 role-object pattern). This enables role-based access control to 4266 be used to restrict which entities can author a given policy. 4267 Note that Role is a type of SUPAPolicyMetadata. 4269 5.16.1. SUPAPolicyTarget Attributes 4271 Currently, no attributes are defined for the SUPAPolicyTarget 4272 class. 4274 5.16.2. SUPAPolicyTarget Relationships 4276 SUPAPolicyTarget participates in a single relationship, 4277 SUPAHasPolicyTarget, as defined in section 5.3.2.3. It also inherits 4278 the SUPAHasPolicyMetadata aggregation (see section 5.17.2.1.). 4280 5.17. The Abstract Class "SUPAPolicyMetadata" 4282 Metadata is information that describes and/or prescribes 4283 characteristics and behavior of another object that is **not** 4284 an inherent, distinguishing characteristic or behavior of that 4285 object (otherwise, it would be an integral part of that object). 4287 For example, a socialSecurityNumber attribute should not be part 4288 of a generic Person class. First, most countries in the world do 4289 not know what a social security number is, much less use them. 4290 Second, a person is not created with a social security number; 4291 rather, a social security number is used to track people for 4292 administering social benefits, though it is also used as a form 4293 of identification. 4295 Continuing the example, a better way to add this capability to a 4296 model would be to have a generic Identification class, then 4297 define a SocialSecurityNumber subclass, populate it as necessary, 4298 and then define a composition between a Person and it (this is a 4299 composition because social security numbers are not reused). 4301 Since social security numbers are given to US citizens, permanent 4302 residents, and temporary working residents, and because it is 4303 also used to administer benefits, the composition is realized 4304 as an association class to define how it is being used. 4306 An example of descriptive metadata for network elements would be 4307 documentation about best current usage practices (this could also 4308 be in the form of a reference). An example of prescriptive 4309 metadata for network elements would be the definition of a time 4310 period during which specific types of operations are allowable. 4312 This is an optional class that defines the top of a hierarchy of 4313 model elements that are used to define different types of metadata 4314 that can be applied to policy and policy component objects. This 4315 enables common metadata to be defined as objects and then reused 4316 when the metadata are applicable. One way to control whether 4317 SUPAPolicyMetadata objects are reused is by using the attributes 4318 of the SUPAHasPolicyMetadataDetail association class. 4320 It is recommended that this class, along with its 4321 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator 4322 subclasses, be used as part of a conformant implementation. It is 4323 defined to be optional, since metadata is not strictly required. 4324 However, metadata can help specify and describe SUPAPolicyObject 4325 entities, and can also be used to drive dynamic behavior. 4327 5.17.1. SUPAPolicyMetadata Attributes 4329 This section defines the attributes of the SUPAPolicyMetadata 4330 class. 4332 5.17.1.1. The Attribute "supaPolMetadataDescription" 4334 This is an optional string attribute that defines a free-form 4335 textual description of this metadata object. 4337 5.17.1.2. The Attribute "supaPolMetadataIDContent" 4339 This is a mandatory string attribute that represents part of the 4340 object identifier of an instance of this class. It defines the 4341 content of the object identifier. It works with another class 4342 attribute, called supaPolMetadataIDEncoding, which defines how to 4343 interpret this attribute. These two attributes form a tuple, 4344 and together enable a machine to understand the syntax and value 4345 of an object identifier for the object instance of this class. 4347 5.17.1.3. The Attribute "supaPolMetadataIDEncoding" 4349 This is an optional non-zero enumerated integer attribute that 4350 represents part of the object identifier of an instance of this 4351 class. It defines the format of the object identifier. It works 4352 with another class attribute, called supaPolMetadataIDContent, 4353 which defines the content of the object ID. 4355 These two attributes form a tuple, and together enable a machine 4356 to understand the syntax and value of an object identifier for 4357 the object instance of this class. The supaPolMetadataIDEncoding 4358 attribute is mapped to the following values: 4360 0: error (i.e., an error state) 4361 1: init (i.e., an initialization state) 4362 2: primary_key 4363 3: foreign_key 4364 4: GUID 4365 5: UUID 4366 6: URI 4367 7: FQDN 4368 8: FQPN 4369 9: string_instance_id 4371 Note that 0 and 1 represent error and initialization states, 4372 respectively. Values 2-8 define the content as a reference. Value 9 4373 defines the content as a string that is the canonical 4374 representation, in ASCII, of an instance ID of this object. 4376 5.17.1.4. The Attribute "supaPolMetadataName" 4378 This is an optional string attribute that defines the name of this 4379 SUPAPolicyMetadata object. 4381 5.17.2. SUPAPolicyMetadata Relationships 4383 SUPAPolicyMetadata participates in two aggregations. The first, 4384 SUPAHasPolicyMetadata, which is defined in the following subsection. 4385 The second, SUPAHasMetadataDecorator, is defined in section 5.19.2. 4387 5.17.2.1. The Aggregation "SUPAHasPolicyMetadata" 4389 This is a mandatory aggregation that defines the set of 4390 SUPAPolicyMetadata that are aggregated by this particular 4391 SUPAPolicyObject. 4393 The multiplicity of this relationship is defined as 0..n on the 4394 aggregate (SUPAPolicyObject) side, and 0..n on the part 4395 (SUPAPolicyMetadata) side. This means that this relationship is 4396 optional. However, it is recommended that this aggregation be used 4397 as part of a conformant implementation, because it enables metadata 4398 to be attached to all objects that inherit from the SUPAPolicyObject 4399 class. The semantics of this aggregation are implemented using the 4400 SUPAHasPolicyMetadataDetail association class. 4402 5.17.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail" 4404 This is a mandatory concrete association class, and defines the 4405 semantics of the SUPAHasPolicyMetadata aggregation. Its purpose is 4406 to determine which SUPAPolicyMetadata object instances should be 4407 attached to which particular object instances of the 4408 SUPAPolicyObject class. This is done by using the attributes and 4409 relationships of the SUPAPolicyMetadataDetail class to constrain 4410 which SUPAPolicyMetadata objects can be aggregated by which 4411 particular SUPAPolicyObject instances. 4413 5.17.2.2.1. The Attribute "supaPolMetadataConstraintEncoding" 4415 This is an optional non-negative enumerated integer that defines 4416 how to interpret each string in the supaPolMetadataConstraint 4417 class attribute. Values include: 4419 0: error 4420 1: init 4421 2: OCL 2.4 4422 3: OCL 2.x 4423 4: OCL 1.x 4424 5: QVT 1.2 - Relations Language 4425 6: QVT 1.2 - Operational language 4426 7: Alloy 4427 8: ASCII Text 4429 Enumerations 0 and 1 signify an error state and an initialization 4430 state, respectively. Enumerations 2-4 are dedicated to OCL (with 4431 OCL 2.4 being the latest version as of this writing). QVT defines a 4432 set of languages [20] (the two most powerful and useful are defined 4433 by enumerations 5 and 6). Alloy is a language for describing 4434 constraints, and uses a SAT solver to guarantee correctness [21]. 4435 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 4436 and hence, not verifiable), but is included for completeness. 4438 If this class is instantiated, then this attribute SHOULD also be 4439 instantiated, and SHOULD be part of a conformant implementation. 4441 5.17.2.2.2. The Attribute "supaPolMetadataConstraint[0..n]" 4443 This is an optional array of string attributes. Each attribute 4444 specifies a constraint to be applied using the format identified 4445 by the value of the supaPolMetadataPolicyConstraintEncoding class 4446 attribute. This provides a more rigorous and flexible treatment of 4447 constraints than is possible in [RFC3460]. 4449 If this class is instantiated, then this attribute SHOULD also be 4450 instantiated, and should be part of a conformant implementation. 4451 Note: [0..n] means that this is a multi-valued property that has 4452 zero or more attributes. 4454 5.17.2.2.3. The Attribute "supaPolMetadataIsApplicable" 4456 This is an optional Boolean attribute. If the value of this 4457 attribute is TRUE, then the SUPAPolicyMetadata object(s) of this 4458 particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated 4459 by this particular SUPAPolicyObject. 4461 5.18. The Concrete Class "SUPAPolicyConcreteMetadata" 4463 This is an optional concrete class. It defines an object that will 4464 be wrapped by concrete instances of the SUPAPolicyMetadataDecorator 4465 class. It can be viewed as a "carrier" for metadata that will be 4466 attached to a subclass of SUPAPolicyObject. Since the decorator 4467 pattern is used, any number of concrete subclasses of the 4468 SUPAPolicyMetadataDecorator class can wrap an instance of the 4469 SUPAPolicyConcreteMetadata class. 4471 It is recommended that this class be used as part of a conformant 4472 implementation. 4474 5.18.1. SUPAPolicyConcreteMetadata Attributes 4476 Currently, two attributes are defined for the 4477 SUPAPolicyConcreteMetadata class, and are described in the 4478 following subsections. 4480 5.18.1.1. The Attribute "supaPolMDValidPeriodEnd" 4482 This is an optional attribute. Its data type should be able to 4483 express a date and a time. This attribute defines the ending 4484 date and time that this Metadata object is valid for. 4486 5.18.1.2. The Attribute "supaPolMDValidPeriodStart" 4488 This is an optional attribute. Its data type should be able to 4489 express a date and a time. This attribute defines the starting 4490 date and time that this Metadata object is valid for. 4492 5.18.2. SUPAPolicyConcreteMetadata Relationships 4494 This class inherits the relationships of the SUPAPolicyMetadata 4495 class; see section 5.17.2. It can also be used by subclasses of 4496 the SUPAPolicyMetadataDecorator class, and hence, can participate 4497 in the SUPAHasMetadataDecorator aggregation; see section 5.19.2. 4499 5.19. The Abstract Class "SUPAPolicyMetadataDecorator" 4501 This is an optional class, and is used to implement the decorator 4502 pattern (see section 4.2.1.2.) for metadata objects. This pattern 4503 enables all or part of one or more SUPAPolicyMetadataDecorator 4504 subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance. 4506 It is recommended that this class be used as part of a conformant 4507 implementation. 4509 5.19.1. SUPAPolicyMetadataDecorator Attributes 4511 Currently, no attributes are defined for this class. 4513 5.19.2. SUPAPolicyMetadataDecorator Relationships 4515 This class inherits the relationships of the SUPAPolicyMetadata 4516 class; see section 5.17.2. It also defines a single aggregation, 4517 SUPAHasMetadataDecorator, which is used to implement the decorator 4518 pattern, as described in the following subsections. 4520 5.19.2.1. The Aggregation "SUPAHasMetadataDecorator" 4522 This is an optional aggregation, and is part of a decorator 4523 pattern. It is used to enable a concrete instance of a 4524 SUPAPolicyMetadataDecorator to dynamically add behavior to a 4525 SUPAPolicyConcreteMetadata object instance. The semantics of this 4526 aggregation are defined by the SUPAHasMetadataDecoratorDetail 4527 association class. 4529 It is recommended that this aggregation be part of a conformant 4530 implementation. 4532 The multiplicity of this aggregation is 0..1 on the aggregate 4533 (SUPAPolicyMetadataDecorator) side and 1..n on the part 4534 (SUPAPolicyMetadata) side. This means that if this aggregation is 4535 defined, then at least one SUPAPolicyMetadata object (e.g., a 4536 concrete subclass of SUPAPolicyMetadataDecorator) must also be 4537 instantiated and wrapped by this SUPAPolicyConcreteMetadata object 4538 instance. The semantics of this aggregation are defined by the 4539 SUPAHasMetadataDecoratorDetail association class. 4541 5.19.2.2. The Association Class "SUPAHasMetadataDecoratorDetail" 4543 This is an optional concrete association class, and defines the 4544 semantics of the SUPAHasMetadataDecorator aggregation. The purpose 4545 of this class is to use the Decorator pattern to determine 4546 which SUPAPolicyMetadataDecorator object instances, if any, are 4547 required to augment the functionality of the 4548 SUPAPolicyConcreteMetadata object instance that is being used. 4549 Three attributes are defined for this class, which are described 4550 in the following subsections. 4552 It is recommended that this association class be part of a 4553 conformant implementation. 4555 5.19.2.2.1. The Attribute "supaPolMetadataDecConstraintEncoding" 4557 This is an optional non-negative enumerated integer that defines 4558 how to interpret each string in the supaPolMetadataDecConstraint 4559 class attribute. Values include: 4561 0: error 4562 1: init 4563 2: OCL 2.4 4564 3: OCL 2.x 4565 4: OCL 1.x 4566 5: QVT 1.2 - Relations Language 4567 6: QVT 1.2 - Operational language 4568 7: Alloy 4569 8: ASCII Text 4571 Enumerations 0 and 1 signify an error state and an initialization 4572 state, respectively. Enumerations 2-4 are dedicated to OCL (with 4573 OCL 2.4 being the latest version as of this writing). QVT defines a 4574 set of languages [20] (the two most powerful and useful are defined 4575 by enumerations 5 and 6). Alloy is a language for describing 4576 constraints, and uses a SAT solver to guarantee correctness [21]. 4577 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 4578 and hence, not verifiable), but is included for completeness. 4580 If this class is instantiated, then this attribute SHOULD also be 4581 instantiated, and SHOULD be part of a conformant implementation. 4583 5.19.2.2.2. The Attribute "supaPolMetadataDecConstraint[0..n]" 4585 This is an optional array of string attributes. Each attribute 4586 specifies a constraint to be applied using the format identified 4587 by the value of the supaPolMetadataDecConstraintEncoding class 4588 attribute. This provides a more rigorous and flexible treatment of 4589 constraints than is possible in [RFC3460]. 4591 If this class is instantiated, then this attribute SHOULD also be 4592 instantiated, and should be part of a conformant implementation. 4593 Note: [0..n] means that this is a multi-valued property that has 4594 zero or more attributes. 4596 5.19.2.2.3. The Attribute "supaPolMetadataDecIsApplicable" 4598 This is an optional Boolean attribute. If the value of this 4599 attribute is TRUE, then the SUPAPolicyMetadataDecorator object(s) of 4600 this particular SUPAHasMetadataDecorator aggregation SHOULD be 4601 aggregated by this particular SUPAPolicyConcreteMetadata object. 4603 5.20. The Concrete Class "SUPAPolicyAccessMetadataDef" 4605 This is an optional concrete class that defines access control 4606 information, in the form of metadata, that can be added to a 4607 SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata 4608 aggregation (see section 5.2.2.). This enables all or part of a 4609 standardized description and/or specification of access control 4610 for a given SUPAPolicyObject to be easily changed at runtime by 4611 wrapping an object instance of the SUPAPolicyConcreteMetadata 4612 class (or its subclass) with all or part of this object, and then 4613 adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata 4614 object instance. 4616 5.20.1. SUPAPolicyAccessMetadataDef Attributes 4618 Currently, the SUPAPolicyAccessMetadataDef class defines three 4619 attributes; these are described in the following subsections. 4621 5.20.1.1. The Attribute "supaPolAccessPrivilegeDef" 4623 This is an optional non-negative enumerated integer attribute. It 4624 specifies the access privileges that external Applications have 4625 when interacting with a specific SUPAPolicyObject that is adorned 4626 with an instance of this SUPAPolicyAccessMetadataDef object. This 4627 enables the management system to control, in a consistent manner, 4628 the set of operations that external Applications have for 4629 SUPAPolicies and components of SUPAPolicies. Values include: 4631 0: error 4632 1: init 4633 2: read only (for all policy components) 4634 3: read and write (for all policy components) 4635 4: privileges are specified by an external MAC model 4636 5: privileges are specified by an external DAC model 4637 6: privileges are specified by an external RBAC model 4638 7: privileges are specified by an external ABAC model 4639 8: privileges are specified by an external custom model 4641 Note that 0 and 1 represent error and initialization states, 4642 respectively. Values 4-8 indicate that a formal external access 4643 control model is used. The name of this model, and its location, 4644 are specified in two other class attributes, called 4645 supaPolAccessPrivilegeModelName and supaPolAccessPrivilegeModelRef. 4647 MAC, DAC, RBAC, and ABAC (values 4-7 stand for Mandatory Access 4648 Control, Discretionary Access Control, Role-Based Access Control, 4649 and Attribute-Based Access Control, respectively. They are defined 4650 in [13]. A value of 8 indicates that a formal external model that 4651 is not MAC, DAC, RBAC, or ABAC is used. 4653 5.20.1.2. The Attribute "supaPolAccessPrivilegeModelName" 4655 This is an optional string attribute that contains the name of 4656 the access control model being used. If the value of the 4657 supaPolAccessPrivilegeDef is 0-2, then the value of this attribute 4658 is not applicable. Otherwise, the text in this class attribute 4659 should be interpreted according to the value of the 4660 supaPolAccessPrivilegeModelRef class attribute. 4662 5.20.1.3. The Attribute "supaPolAccessPrivilegeModelRef" 4664 This is an optional non-negative enumerated integer attribute 4665 that defines the data type of the supaPolAccessPrivilegeModelName 4666 attribute. If the value of the supaPolAccessPrivilegeDef class 4667 attribute is 0-2, then the value of this attribute is not 4668 applicable. Otherwise, the value of this class attribute defines 4669 how to interpret the text in the supaPolAccessPrivilegeModelRef 4670 class attribute. Values include: 4672 0: error 4673 1: init 4674 2: GUID 4675 3: UUID 4676 4: URI 4677 5: FQDN 4678 6: FQPN 4679 7: string_instance_id 4681 Note that 0 and 1 represent error and initialization states, 4682 respectively. Values 2-6 define the content as a reference. Value 7 4683 defines the content as a string that is the canonical 4684 representation, in ASCII, of an instance ID of this object. 4686 5.21. The Concrete Class "SUPAPolicyVersionMetadataDef" 4688 This is an optional concrete class that defines versioning 4689 information, in the form of metadata, that can be added to a 4690 SUPAPolicyObject. This enables all or part of a standardized 4691 description and/or specification of version information for a 4692 given SUPAPolicyObject to be easily changed at runtime by 4693 wrapping an object instance of the SUPAPolicyConcreteMetadata 4694 class (or its subclass) with all or part of this object. 4696 5.21.1. SUPAPolicyVersionMetadataDef Attributes 4698 Version information is defined in a generic format based on the 4699 Semantic Versioning Specification [18] as follows: 4701 ..[][] 4703 where the first three components (major, minor, and patch) MUST be 4704 present, and the latter two components (pre-release and build- 4705 metadata) MAY be present. A version number MUST take the form 4706 .., where , , and are 4707 each non-negative integers that MUST NOT contain leading zeros. 4708 In addition, the value of each of these three elements MUST 4709 increase numerically. In this approach: 4711 o supaVersionMajor denotes a new release; this number MUST be 4712 incremented when either changes are introduced that are not 4713 backwards-compatible, and/or new functionality not previously 4714 present is introduced 4715 o supaVersionMinor denotes a minor release; this number MUST be 4716 incremented when new features and/or bug fixes to a major 4717 release that are backwards-compatible are introduced, and/or 4718 if any features are marked as deprecated 4719 o supaVersionPatch denotes a version that consists ONLY of bug 4720 fixes, and MUST be incremented when these bug fixes are Not 4721 backwards-compatible 4723 When multiple versions exist, the following rules define their 4724 precedence: 4726 1. Precedence MUST be calculated by separating the version into 4727 major, minor, patch, and pre-release identifiers, in that 4728 order. Note that build-metadata is NOT used to calculated 4729 precedence. 4731 2. Precedence is determined by the first difference when 4732 comparing each of these identifiers, from left to right, 4733 as follows: 4734 a. Major, minor, and patch versions are always compared 4735 numerically (e.g., 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1) 4736 b. When major, minor, and patch are equal, a pre-release 4737 version has LOWER precedence than a normal version 4738 (e.g., 1.0.0-alpha < 1.0.0) 4739 c. Precedence for two pre-release versions with the same 4740 major, minor, and patch version MUST be determined by 4741 comparing each dot separated identifier from left to 4742 right until a difference is found as follows: 4743 - identifiers consisting only of digits are compared 4744 numerically and identifiers with letters and/or 4745 hyphens are compared lexically in ASCII sort order 4746 - Numeric identifiers always have lower precedence 4747 than non-numeric identifiers 4748 - A larger set of pre-release fields has a higher 4749 precedence than a smaller set, if all of the 4750 preceding identifiers are equal 4751 3. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha-beta 4752 < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0. 4754 Currently, the SUPAPolicyVersionMetadataDef class defines five 4755 attributes; these are described in the following subsections. 4757 5.21.1.1. The Attribute "supaVersionMajor" 4759 This is a mandatory string attribute, and contains a string 4760 representation of an integer that is greater than or equal to zero. 4761 It indicates that a significant increase in functionality is 4762 present in this version. It MAY also indicate that this version has 4763 changes that are NOT backwards-compatible; this MAY be denoted in 4764 the supaVersionBuildMetadata class attribute. 4766 The special string "0.1.0" is for initial development that MUST 4767 NOT be considered stable. Improvements to this initial version, 4768 before they are released to the public, are denoted by incrementing 4769 the minor and patch version numbers. 4771 The major version X (i.e., X.y.z, where X > 0) MUST be incremented 4772 if any backwards incompatible changes are introduced. It MAY 4773 include minor and patch level changes. The minor and patch version 4774 numbers MUST be reset to 0 when the major version number is 4775 incremented. 4777 5.21.1.2. The Attribute "supaVersionMinor" 4779 This is a mandatory string attribute, and contains a string 4780 representation of an integer that is greater than or equal to zero. 4781 It indicates that this release contains a set of features and/or 4782 bug fixes that MUST be backwards-compatible. 4784 The minor version Y (i.e., x.Y.z, where x > 0) MUST be incremented 4785 if new, backwards-compatible changes are introduced. It MUST be 4786 incremented if any features are marked as deprecated. It MAY be 4787 incremented if new functionality or improvements are introduced. 4788 It MAY include patch level changes. The patch version number MUST 4789 be reset to 0 when the minor version number is incremented. 4791 5.21.1.3. The Attribute "supaVersionPatch" 4793 This is a mandatory string attribute, and contains a string 4794 representation of an integer that is greater than or equal to zero. 4795 It indicates that this version contains ONLY bug fixes. 4797 The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented 4798 if new, backwards-compatible changes are introduced. A bug fix is 4799 defined as an internal change that fixes incorrect behavior. 4801 5.21.1.4. The Attribute "supaVersionPreRelease" 4803 This is an optional string attribute, and contains a string 4804 defining the pre-release version. 4806 A pre-release version MAY be denoted by appending a hyphen and a 4807 series of dot-separated identifiers immediately following the patch 4808 version. Identifiers MUST comprise only ASCII alphanumerics and a 4809 hyphen. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT 4810 include leading zeroes. Pre-release versions have a lower 4811 precedence than the associated normal version. A pre-release version 4812 indicates that the version is unstable and might not satisfy the 4813 intended compatibility requirements as denoted by its associated 4814 normal version. Examples include: 1.0.0-alpha, 4815 1.0.0-alpha.1, 1.0.0-0.3.7, and 1.0.0-x.7.z.92. 4817 5.21.1.5. The Attribute "supaVersionBuildMetadata" 4819 This is an optional string attribute, and contains a string defining 4820 the build metadata. Build metadata MAY be denoted by appending a 4821 plus sign and a series of dot-separated identifiers immediately 4822 following the patch or pre-release version. Identifiers MUST be 4823 made up of only ASCII alphanumerics and a hyphen. Identifiers 4824 MUST NOT be empty. Build metadata SHOULD be ignored when determining 4825 version precedence. Examples include: 1.0.0.-alpha+1, 4826 1.0.0+20130313144700, and 1.0.0-beta+exp.sha.5114f85. 4828 6. SUPA ECAPolicyRule Information Model 4830 This section defines the classes, attributes, and relationships 4831 of the SUPA ECAPolicyRule Information Model (EPRIM). Unless 4832 otherwise stated, all classes (and attributes) defined in this 4833 section were abstracted from DEN-ng [2], and a version of them are 4834 in the process of being added to [5]. 4836 6.1. Overview 4838 Conceptually, the EPRIM is a set of subclasses that specialize the 4839 concepts defined in the GPIM for representing the components of a 4840 Policy that uses ECA semantics. This is shown in Figure 26 (only 4841 new EPRIM subclasses and their GPIM superclasses are shown; note 4842 that the SUPAPolicyMetadata hierarchy is used **as is**). 4844 (Class of another model that SUPA is integrating into) 4845 | 4846 +---SUPAPolicyObject (5.2) 4847 | 4848 +---SUPAPolicyStructure (5.3) 4849 | | 4850 | +---SUPAECAPolicyRule (6.4) 4851 | | 4852 | +---SUPAECAPolicyRuleAtomic (6.5) 4853 | | 4854 | +---SUPAECAPolicyRuleComposite (6.6) 4855 | 4856 +---SUPAPolicyComponentStructure (5.4) 4857 | 4858 +---SUPAPolicyClause (5.5) 4859 | | 4860 | +---SUPABooleanClause (6.7) 4861 | | 4862 | +---SUPABooleanClauseAtomic (6.8) 4863 | | 4864 | +---SUPABooleanClauseComposite (6.9) 4865 | 4866 +---SUPAPolicyClauseComponentDecorator (5.7) 4867 | 4868 +---SUPAECAComponent(6.10) 4869 | 4870 +---SUPAPolicyEvent (6.11) 4871 | 4872 +---SUPAPolicyCondition (6.12) 4873 | 4874 +---SUPAPolicyAction (6.13) 4876 Figure 26. The EPRIM Class Hierarchy 4878 Specifically, the EPRIM specializes the SUPAPolicyStructure class 4879 class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it 4880 also specializes two subclasses of the SUPAPolicyComponentStructure 4881 class to create two new sets of policy components. These two 4882 SUPAPolicyComponentStructure subclasses are: 4884 o a new subclass of SUPAPolicyClause, called SUPABooleanClause 4885 (see sections 6.7 - 6.9), is defined for constructing Boolean 4886 clauses that are specific to the needs of ECA Policy Rules 4887 o a new subclass of SUPAPolicyClauseComponentDecorator, called 4888 SUPAECAComponent (see sections 6.10 - 6.13), is defined for 4889 constructing reusable objects that represent Events, 4890 Conditions, and Actions 4892 The EPRIM provides new functionality, based on the GPIM, by 4893 extending the GPIM to define new classes and relationships. The 4894 EPRIM does NOT define new classes that are not inherited from 4895 existing GPIM classes. This ensures that the semantics of the GPIM 4896 are not changed, even though new functionality (for ECA Policy 4897 Rules and components) are being defined. 4899 The overall strategy for refining the GPIM is as follows: 4901 o SUPAECAPolicyRule is defined as a subclass of the GPIM 4902 SUPAPolicyStructure class 4903 o A SUPAECAPolicyRule has event, condition, and action clauses 4904 o Conceptually, this can be viewed as three aggregations 4905 between the SUPAECAPolicyRule and each clause 4906 o Each aggregation uses an instance of a concrete subclass of 4907 SUPAPolicyClause; this can be a SUPABooleanClause 4908 (making it ECA-specific), a SUPAEncodedClause (making it 4909 generic in nature), or a new subclass of SUPAPolicyClause 4910 o Concrete subclasses of SUPAPolicyClause may be decorated 4911 with zero or more concrete subclasses of the 4912 SUPAPolicyComponentDecorator class 4913 o An optional set of GPIM SUPAPolicySource objects can be 4914 defined to represent the authoring of a SUPAECAPolicyRule 4915 o An optional set of GPIM SUPAPolicyTarget objects can be 4916 defined to represent the set of managed entities that will be 4917 affected by this SUPAECAPolicyRule 4918 o An optional set of SUPAPolicyMetadata can be defined for any 4919 of the objects that make up a SUPAECAPolicyRule, including 4920 any of its components 4922 6.2. Constructing a SUPAECAPolicyRule 4924 There are several different ways to construct a SUPAECAPolicyRule; 4925 they differ in which set of components are used to define the 4926 content of the SUPAECAPolicyRule, and whether each component is 4927 decorated or not. The following are some examples of creating a 4928 SUPAECAPolicyRule: 4930 o Define three types of SUPABooleanClauses, one each for the 4931 event, condition, and action clauses that make up a 4932 SUPAECAPolicyRule, and then 4933 o For one or more of the above clauses, associate an 4934 appropriate set of SUPAPolicyEvent, SUPAPolicyCondition, or 4935 SUPAPolicyAction objects, and complete the clause using an 4936 appropriate SUPAPolicyOperator and a corresponding 4937 SUPAPolicyValue or SUPAPolicyVariable (e.g., resulting in 4938 the phrase "SUPAPolicyAction = SUPAPolicyEvent") 4939 o Define a SUPAPolicyCollection component, which is used to 4940 aggregate a set of objects appropriate for a clause, and 4941 complete the clause using an appropriate SUPAPolicyOperator 4942 and a corresponding SUPAPolicyValue or SUPAPolicyVariable 4943 o Create a new concrete subclass of 4944 SUPAPolicyClauseComponentDecorator (i.e., a sibling class of 4945 SUPAECAComponent) that can wrap concrete instances of 4946 SUPAPolicyClause (i.e., SUPABooleanClause); note that this 4947 approach enables the new concrete subclass of 4948 SUPAPolicyClauseComponentDecorator to optionally be decorated 4949 as well 4950 o Create a new concrete subclass of SUPAPolicyStructure that 4951 provides ECA-specific functionality, and define all or part 4952 of its content by aggregating a set of SUPAPolicyClauses 4954 Note that compound Boolean clauses may be formed using one or more 4955 SUPABooleanClauseComposite objects with one or more 4956 SUPABooleanClauseAtomic objects. 4958 6.3. Working With SUPAECAPolicyRules 4960 A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that 4961 MUST have three clauses, defined as follows: 4963 o The event clause defines a Boolean expression that, if TRUE, 4964 triggers the evaluation of its condition clause (if the 4965 event clause is not TRUE, then no further action for this 4966 policy rule takes place). 4967 o The condition clause defines a Boolean expression that, if 4968 TRUE, enables the actions in the action clause to be executed 4969 (if the condition clause is not TRUE, then no further action 4970 for this policy rule takes place). 4972 o The action clause contains a set of actions that MAY be 4973 executed; which particular actions are executed are defined 4974 by metadata and the supaECAEvalStrategy attribute (see 4975 section 6.6.1.1.). 4977 Each of the above clauses can be a simple Boolean expression (of 4978 the form {variable operator value}, or a compound Boolean 4979 expression consisting of Boolean combinations of clauses. 4980 Compound Boolean expressions SHOULD be in CNF or DNF. 4982 Note that each of the above three clauses MAY have a set of 4983 SUPAPolicyMetadata objects that can constrain, or otherwise 4984 affect, how that clause is treated. For example, a set of 4985 SUPAPolicyMetadata MAY affect whether none, some, or all actions 4986 are executed, and what happens if an action fails. 4988 Each of the three clauses can be constructed from either a 4989 SUPAEncodedClause or a SUPABooleanClause. The advantage of using 4990 SUPAEncodedClauses is simplicity, as the content of the clause is 4991 encoded directly into the attributes of the SUPAEncodedClause. The 4992 advantage of using SUPABooleanClauses is reusability, since each 4993 term in each clause is potentially a reusable object. 4995 Since a SUPABooleanClause is a subclass of a SUPAPolicyClause 4996 (see Section 6.7), it can be decorated by one or more concrete 4997 subclasses of SUPAPolicyClauseComponentDecorator. Therefore, a 4998 SUPAECAPolicyRule can be built entirely from objects defined in 4999 the GPIM and EPRIM, which facilitates the construction of 5000 SUPAPolicies by a machine. 5002 The relation between a SUPAECAPolicyRule and a SUPAPolicyClause 5003 is shown in Figure 27, and is further explained in Section 6.4. 5005 A A 5006 +---------------------+ +------------------+ 5007 | |/ \ SUPAHasPolicyClause \| | 5008 | SUPAPolicyStructure | A ---------+------------+ SUPAPolicyClause | 5009 | |\ / ^ /| | 5010 +---------+-----------+ 0..n | 1..n +--------+---------+ 5011 / \ | / \ 5012 I | I 5013 A I | A I 5014 +-------+-----------+ | +--------+----------+ 5015 | SUPAECAPolicyRule | | | SUPABooleanClause | 5016 +-------------------+ | +-------------------+ 5017 | 5018 A | 5019 +---------------+-----------+ 5020 | SUPAHasPolicyClauseDetail | 5021 +---------------------------+ 5023 Figure 27. SUPAECAPolicyRule Clauses 5025 The SUPAHasPolicyClause aggregation is implemented using the 5026 SUPAHasPolicyClauseDetail association class. These were 5027 described in sections 5.3.2.7 and 5.3.2.8, respectively. 5029 6.4. The Abstract Class "SUPAECAPolicyRule" 5031 This is a mandatory abstract class, which is a PolicyContainer 5032 that aggregates PolicyEvents, PolicyConditions, PolicyActions into 5033 a type of policy rule known as an Event-Condition-Action (ECA) 5034 policy rule. As previously explained, this has the following 5035 semantics: 5037 IF the event clause evaluates to TRUE 5038 IF the condition clause evaluates to TRUE 5039 THEN execute actions in the action clause 5040 ENDIF 5041 ENDIF 5043 The event clause, condition clause, and action clause collectively 5044 form a three-tuple. Each clause MUST be defined by at least one 5045 SUPAPolicyClause (which MAY be decorated with other elements, 5046 using concrete subclasses of the SUPAPolicyClauseComponentDecorator 5047 class, as described in section 5.7). 5049 Each of the three types of clauses is a 3-tuple of the form: 5051 {variable operator value} 5053 Each of the three clauses MAY be combined with additional clauses 5054 using any combination of logical AND, OR, and NOT operators; this 5055 forms a "compound" Boolean clause. For example, if A, B, and C are 5056 three attributes in an event, then a valid event clause could be: 5058 (A AND B) OR C 5060 Note that the above expression is in DNF; the equivalent CNF form 5061 is ((A OR C) AND (B OR C)). In either case, the output of all 5062 three clauses is either TRUE or FALSE; this facilitates combining 5063 and chaining SUPAECAPolicyRules. 5065 An action clause MAY invoke a SUPAPolicyAction from the same or a 5066 different SUPAECAPolicyRule. However, a SUPAPolicy MUST NOT be 5067 called directly by a SUPAECAPolicyRule action clause; this is 5068 because the semantics of a SUPAECAPolcyRule dictate that some type 5069 of event triggers its evaluation (among other reasons). 5071 An ECAPolicyRule MAY be optionally augmented with SUPAPolicySource 5072 and/or SUPAPolicyTarget objects (see sections 5.15 and 5.16, 5073 respectively). 5075 All objects that make up a SUPAECAPolicyRule MAY have 5076 SUPAPolicyMetadata objects (see section 5.17) attached to them to 5077 further describe and/or specify behavior. 5079 When defined in an information model, each of the event, condition, 5080 and action clauses MUST be represented as an aggregation between a 5081 SUPAECAPolicyRule (the aggregate) and a set of event, condition, 5082 or action objects (the components). However, a data model MAY map 5083 these definitions to a more efficient form (e.g., by flattening 5084 these three types of object instances, along with their respective 5085 aggregations, into a single object instance). 5087 The composite pattern [3] is applied to the SUPAECAPolicyRule 5088 class, enabling its (concrete) subclasses to be used as either a 5089 stand-alone policy rule or as a hierarchy of policy rules. 5090 SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both 5091 inherit from SUPAECAPolicyRule. This means that they are both 5092 a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule 5093 aggregation enables a particular SUPAECAPolicyRuleComposite 5094 object to aggregate both SUPAECAPolicyRuleComposite as well as 5095 SUPAECAPolicyRuleAtomic objects. In contrast, a 5096 SUPAECAPolicyRuleAtomic can NOT aggregate either a 5097 SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. 5098 SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are 5099 defined in sections 6.5 and 6.6, respectively. This is 5100 shown in Figure 28. 5102 A 5103 1..n +-------------------+ 5104 \| | 5105 +--------------- + SUPAECAPolicyRule | 5106 | /| | 5107 | +--------+----------+ 5108 | / \ 5109 | SUPAHasECAPolicyRule I 5110 | I 5111 | I 5112 | I 5113 | +---------------+-------------+ 5114 | I I 5115 / \ I I 5116 A I I 5117 C \ / 0..1 I C I 5118 +-----+---------+----------+ +-----------+-----------+ 5119 |SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic| 5120 +--------------------------+ +-----------------------+ 5122 Figure 28. The Composite Pattern Applied to a SUPAECAPolicyRule 5123 Note that the HasSUPAECAPolicyRule aggregation is defined by the 5124 HasSUPAECAPolicyRuleDetail association class; both are defined 5125 in sections 6.6.2 and 6.6.3, respectively. 5127 6.4.1. SUPAECAPolicyRule Attributes 5129 Currently, the SUPAECAPolicyRule defines two attributes, as 5130 described in the following subsections. 5132 6.4.1.1. The Attribute "supaECAPolicyRulePriority" 5134 This is a mandatory non-negative integer attribute that defines 5135 the priority of this particular SUPAECAPolicyRule. A larger value 5136 indicates a higher priority. A default value of 0 MAY be assigned. 5138 Priority is used primarily for 2 reasons: (1) to resolve conflicts 5139 among policy actions (e.g., given a set of conflicting actions, 5140 which one will execute) and (2) to define the execution order of 5141 policy actions (e.g., when one action may depend on the output of 5142 one or more previous actions). 5144 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" 5146 This is an optional non-negative enumerated integer whose value 5147 defines the current status of this policy rule. Values include: 5149 0: error 5150 1: init 5151 2: In development, not ready to be deployed 5152 1: Ready to be deployed 5153 2: Deployed but not enabled 5154 3: Deployed and enabled, but not executed 5155 4: Executed without errors 5156 5: Executed with errors 5157 6: Aborted during execution 5159 Note that 0 and 1 represent error and initialization states, 5160 respectively. 5162 6.4.2. SUPAECAPolicyRule Relationships 5164 Currently, the SUPAECAPolicyRule does not define any 5165 relationships. It inherits all four relationships defined by 5166 the SUPAPolicyStructure class (see section 5.3.2.). 5168 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" 5170 This is a mandatory concrete class. This class is a type of 5171 PolicyContainer, and represents a SUPAECAPolicyRule that can 5172 operate as a single, stand-alone, manageable object. 5174 Put another way, a SUPAECAPolicyRuleAtomic object can NOT be modeled 5175 as a set of hierarchical SUPAECAPolicyRule objects; if this is 5176 required, then a SUPAECAPolicyRuleComposite object should be 5177 used instead. 5179 6.5.1. SUPAECAPolicyRuleAtomic Attributes 5181 Currently, the SUPAECAPolicyRuleAtomic class defines a single 5182 attribute, as described in the following subsection. 5184 6.5.1.1. The Attribute "supaECAPolActionEvalStrategy" 5186 This is a mandatory, non-zero, integer attribute that enumerates 5187 a set of allowable alternatives that define how the set of 5188 SUPAPolicyAction object instances in a SUPAECAPolicyRuleAtomic 5189 object instance are evaluated. It is assumed that the event and 5190 condition clauses of this SUPAECAPolicyRule have evaluated to TRUE. 5191 This attribute controls which SUPAPolicyActions are executed for a 5192 given SUPAPolicyRuleAtomic object instance when it contains multiple 5193 SUPAPolicyActions. Values include: 5195 0: error 5196 1: init 5197 2: execute the first SUPAPolicyAction in the SUPAPolicyRuleAtomic 5198 object and then terminate 5199 3: execute the last SUPAPolicyAction in the SUPAPolicyRuleAtomic 5200 object and then terminate 5201 4: execute only the highest priority SUPAPolicyAction(s) in 5202 the SUPAPolicyRuleAtomic object and then terminate 5203 5: execute all SUPAPolicyActions in prioritized order (if 5204 any) regardless of whether other SUPAPolicyActions 5205 succeed or fail 5206 6: execute all SUPAPolicyActions in prioritized order (if 5207 any) until at least one SUPAPolicyAction fails, and then 5208 terminate 5210 Note that 0 and 1 represent error and initialization states, 5211 respectively. Values 2 and 3 MUST execute a single SUPAPolicyAction, 5212 and then terminate execution of the SUPAECAPolicyRuleAtomic object. 5213 If the value of supaECAPolActionEvalStrategy is 4, 5 or 6, then all 5214 SUPAPolicyActions that have a priority will be executed first, 5215 starting with the SUPAPolicyAction(s) that have the highest 5216 priority, and then descending in prioritized order. During this 5217 process, any SUPAPolicyActions that have the SAME priority MAY be 5218 executed in any order. After all SUPAPolicyActions that have an 5219 associated priority have executed, then all SUPAPolicyAction(s) that 5220 do not have a priority are then executed (in any order). 5222 Assume that the actions in a given SUPAPolicyAction are defined 5223 as follows: 5225 SUPAPolicyAction A, priority 0 5226 SUPAPolicyAction B, priority 10 5227 SUPAPolicyAction C, priority 5 5228 SUPAPolicyAction D, no priority 5229 SUPAPolicyAction E, no priority 5231 Then, if the supaECAPolActionEvalStrategy attribute value equals: 5233 0: an error is issued 5234 1: this SUPAPolicyAction MUST NOT be used (since it is not yet 5235 properly initialized) 5236 2: only SUPAPolicyAction A is executed 5237 3: only SUPAPolicyAction E is executed 5238 4: only SUPAPolicyAction B is executed 5239 5: all SUPAPolicyActions are executed, regardless of any 5240 failures; the order of execution is B, then C, then A, then 5241 one of either D or E, then the other of D or E 5242 6: all SUPAPolicyActions are executed until a failure is 5243 detected, and then execution for all SUPAPolicyActions 5244 terminate; the execution order (up to the occurrence of the 5245 failure) is B, then C, then A, then one of either D or E, then 5246 the other of D or E 5248 6.5.2. SUPAECAPolicyRuleAtomic Relationships 5250 Currently, the SUPAECAPolicyRuleAtomic class does not define any 5251 relationships. 5253 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" 5255 This is a mandatory concrete class. This class is a type of 5256 PolicyContainer, and represents a SUPAECAPolicyRule as a hierarchy 5257 of SUPAPolicy objects, where the hierarchy contains instances of a 5258 SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects. 5259 Each of the SUPAPolicy objects, including the outermost 5260 SUPAECAPolicyRuleComposite object, are separately manageable. More 5261 importantly, each SUPAECAPolicyRuleComposite object represents an 5262 aggregated object that is itself manageable. 5264 The difference between a SUPAECAPolicyRuleComposite and ability 5265 SUPAECAPolicyRuleAtomic is that each SUPAECAPolicyRuleComposite 5266 defines its own scope. This means that all instances of the 5267 SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite classes 5268 will execute according to their priorities. This means that the 5269 priority of the SUPAECAPolicyRuleComposite object is used to 5270 determine the position that its containing SUPAPolicyActions will 5271 be executed; the priorities of the contained SUPAPolicyActions are 5272 then used. Consider the following example: 5274 +--A (SUPAECAPolicyRuleAtomic), priority 5 5275 | 5276 +--B (SUPAECAPolicyRuleAtomic), priority 0 5277 | 5278 +--C (SUPAECAPolicyRuleComposite), priority 10 5279 | | 5280 | +--C1 (SUPAECAPolicyRuleAtomic), priority 2 5281 | | 5282 | +--C2 (SUPAECAPolicyRuleAtomic), priority 1 5283 | 5284 +--D (SUPAECAPolicyRuleAtomic), no priority 5286 The execution order will be C1, followed by C2, followed by A, 5287 followed by B, followed by D. 5289 6.6.1. SUPAECAPolicyRuleComposite Attributes 5291 Currently, the SUPAECAPolicyRuleComposite class defines one 5292 attribute, as described in the following subsection. 5294 6.6.1.1. The Attribute "supaECAEvalRuleStrategy" 5296 This is a mandatory, non-zero, integer attribute that enumerates 5297 a set of allowable alternatives that define how the set of 5298 SUPAPolicyAction object instances in a SUPAECAPolicyRuleComposite 5299 object are evaluated. It is assumed that the event and condition 5300 clauses of the SUPAECAPolicyRuleComposite have evaluated to TRUE 5301 (e.g., the event has occurred and the conditions were met). 5302 Values include: 5304 0: error 5305 1: init 5306 2: execute the first SUPAPolicyAction in the 5307 SUPAECAPolicyRuleComposite object and then terminate 5308 3: execute the last SUPAPolicyAction in the 5309 SUPAECAPolicyRuleComposite object and then terminate 5310 4: execute only the highest priority SUPAPolicyAction(s) in 5311 the SUPAECAPolicyRuleComposite object and then terminate 5312 5: execute all SUPAPolicyActions in prioritized order (if 5313 any) in that particular SUPAECAPolicyRuleComposite object, 5314 regardless of whether other SUPAPolicyActions succeed or fail 5315 6: execute all SUPAPolicyActions in prioritized order (if 5316 any) in that particular SUPAECAPolicyRuleComposite object 5317 until at least one SUPAPolicyAction fails, and then terminate 5319 Note that 0 and 1 represent error and initialization states, 5320 respectively. Values 2 and 3 MUST execute a single SUPAPolicyAction, 5321 and then terminate execution of all SUPAPolicyActions in this 5322 SUPAECAPolicyRuleComposite object. 5324 If the value of the supaECAEvalStrategy attribute is 4, 5 or 6, then 5325 all SUPAPolicyActions that have a priority will be executed first, 5326 starting with the SUPAPolicyAction(s) that have the highest 5327 priority, and then descending in prioritized order. During this 5328 process, any SUPAPolicyActions that have the SAME priority MAY be 5329 executed in any order. After all SUPAPolicyActions that have an 5330 associated priority have executed, then all SUPAPolicyAction(s) that 5331 do not have a priority are then executed (in any order). 5333 Assume that a SUPAECAPolicyRuleComposite object contains three 5334 SUPAECAPolicyRuleAtomic objects as well as one 5335 SUPAECAPolicyRuleComposite object (that contains two 5336 SUPAECAPolicyRuleAtomic objects), as shown below. 5338 Z (SUPAECAPolicyRuleComposite) 5339 | 5340 +--A (SUPAECAPolicyRuleAtomic), priority 5 5341 | 5342 +--B (SUPAECAPolicyRuleAtomic), priority 0 5343 | 5344 +--C (SUPAECAPolicyRuleComposite), priority 10 5345 | | 5346 | +--C1 (SUPAECAPolicyRuleAtomic), priority 2 5347 | | 5348 | +--C2 (SUPAECAPolicyRuleAtomic), priority 1 5349 | 5350 +--D (SUPAECAPolicyRuleAtomic), no priority 5352 Then, if the supaECAEvalStrategy attribute value of Z equals: 5354 0: an error is issued 5355 1: all SUPAPolicyActions MUST NOT be used (since their containing 5356 SUPAECAPolicyRuleComposite object is not properly initialized) 5357 2: only SUPAPolicyAction A is executed 5358 3: only SUPAPolicyAction D is executed 5359 4: two SUPAPolicyActions are executed: C1, followed by C2 5360 5: all SUPAPolicyActions are executed, regardless of any 5361 failures; the order of execution is C1, then C2, then A, then 5362 B, then D 5363 6: all SUPAPolicyActions are executed until a failure is 5364 detected, and then execution for all SUPAPolicyActions 5365 terminate; the execution order (up to the occurrence of the 5366 failure) is C1, then C2, then A, then B, then D 5368 Note that the supaECAEvalRuleStrategy defines the same semantics as 5369 the supaECAPolActionEvalStrategy. The difference is that the former 5370 is applied to a SUPAECAPolicyRuleComposite object, and the latter is 5371 applied to a SUPAECAPolicyRuleAtomic object. 5373 6.6.2. SUPAECAPolicyRuleComposite Relationships 5375 Currently, the SUPAECAPolicyRuleComposite defines a single 5376 aggregation between it and SUPAECAPolicyRule, as described below. 5378 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" 5380 This is an optional aggregation that implements the composite 5381 pattern. The multiplicity of this aggregation is 0..1 on the 5382 aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part 5383 (SUPAECAPolicyRule) side. This means that if this aggregation 5384 is defined, then at least one SUPAECAPolicyRule object (which may 5385 be either an instance of a SUPAECAPolicyRuleAtomic or a 5386 SUPAECAPolicyRuleComposite class) must also be instantiated and 5387 aggregated by this particular SUPAECAPolicyRuleComposite object. 5388 The semantics of this aggregation are defined by the 5389 SUPAHasECAPolicyRuleDetail association class. 5391 6.6.2.2. The Association Class "SUPAHasECAPolicyRuleDetail" 5393 This is an optional concrete association class, and defines the 5394 semantics of the SUPHasECAPolicyRule aggregation. This enables the 5395 attributes and relationships of the SUPAHasECAPolicyRuleDetail 5396 class to be used to constrain which SUPAECAPolicyRule objects 5397 can be aggregated by this particular SUPAECAPolicyRuleComposite 5398 object instance. It contains a single attribute, defined below. 5400 6.6.2.2.1. The Attribute "supaECAPolicyIsDefault" 5402 This is an optional Boolean attribute. If the value of this 5403 attribute is true, then this SUPAECAPolicyRule is a default 5404 policy, and will be executed if no other SUPAECAPolicyRule 5405 in the SUPAECAPolicyRuleComposite container has been executed. 5406 This is a convenient way for error handling, though care should 5407 be taken to ensure that only one default policy rule is defined 5408 per SUPAECAPolicyRuleComposite container. 5410 6.7. The Abstract Class "SUPABooleanClause" 5412 A SUPABooleanClause specializes a SUPAPolicyClause, and defines 5413 a Boolean expression consisting of a standard structure in the 5414 form of a SUPAPolicyVariable, a SUPAPolicyOperator, and a 5415 SUPAPolicyValue. For example, this enables the following Boolean 5416 clause to be defined: 5418 Foo >= Baz 5420 where 'Foo' is a PolicyVariable, '>=' is a PolicyOperator, and 5421 'Baz' is a PolicyValue. 5423 Note that in this approach, the SUPAPolicyVariable and 5424 SUPAPolicyValue terms are defined as an appropriate subclass of 5425 the SUPAPolicyComponentDecorator class; it is assumed that the 5426 SUPAPolicyOperator is an instance of the SUPAPolicyOperator class. 5427 This enables the EPRIM, in conjunction with the GPIM, to be used 5428 as a reusable class library. This encourages interoperability, 5429 since each element of the clause is itself an object defined by 5430 the SUPA object hierarchy. 5432 An entire SUPABooleanClause may be negated by setting the 5433 supaBoolClauseIsNegated class attribute of the SUPABooleanClause 5434 class to TRUE. Individual terms of a Boolean clause can be negated 5435 by using the supaTermIsNegated Boolean attribute in the 5436 SUPAPolicyTerm class (see section 5.10). 5438 A PolicyClause is in Conjunctive Normal Form (CNF) if it is a 5439 sequence of logically ANDed terms, where each term is a sequence 5440 of logically ORed terms. A PolicyClause is in Disjunctive Normal 5441 Form (DNF) if it is a sequence of logically ORed terms, where each 5442 term is a sequence of logically ANDed terms. 5444 The construction of more complex clauses, which consist of a set 5445 of simple clauses in CNF or DNF (as shown in the above example), 5446 is provided by using the composite pattern [3] to construct two 5447 concrete subclasses of the abstract SUPABooleanClause class. These 5448 are called SUPABooleanClauseAtomic and SUPABooleanClauseComposite, 5449 and are defined in sections 6.8 and 6.9, respectively. This 5450 enables instances of either a SUPABooleanClauseAtomic and/or a 5451 SUPABooleanClauseComposite to be aggregated into a 5452 SUPABooleanClauseComposite object. 5454 6.7.1. SUPABooleanClause Attributes 5456 The SUPABooleanClause class currently defines three attributes, 5457 which are defined in the following subsections. 5459 6.7.1.1. The Attribute "supaBoolClauseBindValue" 5461 This is a mandatory non-zero integer attribute, and defines the 5462 order in which terms bind to a clause. For example, the Boolean 5463 expression "((A AND B) OR (C AND NOT (D OR E)))" has the following 5464 binding order: terms A and B have a bind value of 1; term C has a 5465 binding value of 2, and terms D and E have a binding value of 3. 5467 6.7.1.2. The Attribute "supaBoolClauseIsCNF" 5469 This is an optional Boolean attribute. If the value of this 5470 attribute is TRUE, then this SUPABooleanClauseComposite is in CNF 5471 form. Otherwise, it is in DNF form. 5473 6.7.1.3. The Attribute "supaBoolClauseIsNegated" 5475 This is a mandatory Boolean attribute. If the value of this 5476 attribute is TRUE, then this (entire) SUPABooleanClause is 5477 negated. Note that the supaPolTermIsNegated class attribute of 5478 the SUPAPolicyTerm class is used to negate a single term. 5480 6.7.2. SUPABooleanClause Relationships 5482 Currently, no relationships are defined for this class. 5484 6.8. The Concrete Class "SUPABooleanClauseAtomic" 5486 This is a mandatory concrete class that represents a 5487 SUPABooleanClause that can operate as a single, stand-alone, 5488 manageable object. A SUPABooleanClauseAtomic object can NOT be 5489 modeled as a set of hierarchical clauses; if this functionality is 5490 required, then a SUPABooleanClauseComposite object must be used. 5491 Examples of Boolean clauses that could be contained in a 5492 SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P 5493 and Q are literals (e.g., a variable name that can be either true 5494 or false, or a formula that evaluates to a literal). Examples of 5495 Boolean clauses that are NOT in CNF are NOT(P AND Q), 5496 (P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent 5497 forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and 5498 P AND (Q OR S) AND (Q OR S), respectively. 5500 6.8.1. SUPABooleanClauseAtomic Attributes 5502 No attributes are currently defined for this class. 5504 6.8.2. SUPABooleanClauseAtomic Relationships 5506 Currently, no relationships are defined for this class. 5508 6.9. The Concrete Class "SUPABooleanClauseComposite" 5510 This is a mandatory concrete class that represents a 5511 SUPABooleanClause that can operate as a hierarchy of 5512 SUPAPolicyClause objects, where the hierarchy contains instances of 5513 SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite 5514 objects. Each of the SUPABooleanClauseAtomic and 5515 SUPABooleanClauseComposite objects, including the outermost 5516 SUPABooleanClauseComposite object, are separately manageable. 5517 More importantly, each SUPABooleanClauseComposite object 5518 represents an aggregated object that is itself manageable. 5520 Examples of Boolean clauses that could be contained in a 5521 SUPABooleanClauseComposite object include ((P OR Q) AND R), and 5522 ((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, and 5523 T are literals. 5525 6.9.1. SUPABooleanClauseComposite Attributes 5527 No attributes are currently defined for this class. 5529 6.9.2. SUPABooleanClauseComposite Relationships 5531 Currently, the SUPABooleanClauseComposite class defines a single 5532 aggregation, which is described in the following subsection. 5534 6.9.2.1. The Aggregation "SUPAHasBooleanClause" 5536 This is a mandatory aggregation that defines the set of 5537 SUPABooleanClause objects that are aggregated by this 5538 SUPABooleanClauseComposite object. 5540 The multiplicity of this relationship is 0..1 on the aggregate 5541 (SUPABooleanClauseComposite) side, and 1..n on the part 5542 (SUPABooleanClause) side. This means that one or more 5543 SUPABooleanClauses are aggregated and used to define this 5544 SUPABooleanClauseComposite object. The 0..1 cardinality on the 5545 SUPABooleanClauseComposite side is necessary to enable 5546 SUPABooleanClauses to exist (e.g., in a PolicyRepository) before 5547 they are used by a SUPABooleanClauseComposite. The semantics of 5548 this aggregation is defined by the SUPAHasBooleanClauseDetail 5549 association class. 5551 6.9.2.2. The Association Class "SUPAHasBooleanClauseDetail" 5553 This is a mandatory concrete association class that defines the 5554 semantics of the SUPAHasBooleanClause aggregation. This enables the 5555 attributes and relationships of the SUPAHasBooleanClauseDetail 5556 class to be used to constrain which SUPABooleanClause objects 5557 can be aggregated by this particular SUPABooleanClauseComposite 5558 object instance. 5560 6.9.2.2.1. The Attribute "supaIsHornClause" 5562 This is an optional attribute of type Boolean. If the value of this 5563 attribute is TRUE, then this SUPABooleanClause is a Horn clause. 5564 This has important properties for logic programming and model 5565 theory. For example, a Horn clause is able to express implication 5566 of one variable from a set of other variables. 5568 6.10. The Abstract Class "SUPAECAComponent" 5570 This is a mandatory abstract class that defines three concrete 5571 subclasses, one each to represent the concepts of reusable events, 5572 conditions, and actions. They are called SUPAPolicyEvent, 5573 SUPAPolicyCondition, and SUPAPolicyAction, respectively. 5575 SUPAECAComponents provide two different ways to construct 5576 SUPAPolicyClauses. The first is for the SUPAECAComponent to be 5577 used as either a SUPAPolicyVariable or a SUPAPolicyValue, and the 5578 second is for the SUPAECAComponent to contain the entire clause 5579 text. 5581 For example, suppose it is desired to define a policy condition 5582 clause with the text 'queueDepth > 10'. Two approaches could 5583 satisfy this as follows: 5585 Approach #1 (canonical form): 5586 SUPAPolicyCondition.supaPolicyConditionData contains the text 5587 'queueDepth' 5588 SUPAPolicyOperator.supaPolOpType is set to '1' (greater than) 5589 SUPAPolicyValue.supaPolValContent is set to '10' 5591 Approach #2 (SUPAECAComponent represents the entire clause): 5592 SUPAPolicyCondition.supaPolicyConditionData contains the text 5593 'queueDepth > 10' 5595 The class attribute supaECACompIsTerm, defined in subsection 5596 6.10.1.1, is used to identify which of these two approaches is 5597 used by an object instance of this class. 5599 6.10.1. SUPAECAComponent Attributes 5601 A single attribute is currently defined for this class, and is 5602 described in the following subsection. 5604 6.10.1.1. The Attribute "supaECACompIsTerm" 5606 This is an optional Boolean attribute. If the value of this 5607 attribute is TRUE, then this SUPAECAComponent is used as the value 5608 of a SUPAPolicyTerm to construct a SUPAPolicyClause (this is 5609 approach #1 in section 6.10 above). If the value of this attribute 5610 is FALSE, then this SUPAECAComponent contains the text of the 5611 entire corresponding SUPAPolicyClause (this is approach #2 in 5612 section 6.10 above). 5614 6.10.2. SUPAECAComponent Relationships 5616 No relationships are currently defined for this class. 5618 6.11. The Concrete Class "SUPAPolicyEvent" 5620 This is a mandatory concrete class that represents the concept of 5621 an Event that is applicable to a policy management system. Such 5622 an Event is defined as anything of importance to the management 5623 system (e.g., a change in the system being managed and/or its 5624 environment) occuring on a time-axis (as defined in [19]). 5626 It should be noted that instances of this class are not themselves 5627 events. Rather, instances of this class appear in SUPAPolicyClauses 5628 to describe what types of events the SUPAPolicy is triggered by 5629 and/or uses. 5631 SUPAPolicyEvents can be used as part of a SUPAPolicyClause; this 5632 is done by specifying the attribute name and value of an Event in 5633 the supaPolicyEventData attribute of the SUPAPolicyEvent. This 5634 enables event attributes to be used as part of a SUPAPolicyClause. 5636 Information from events that trigger SUPAPolicies need to be made 5637 available for use in condition and action clauses, as well as 5638 inappropriate decorator objects. Subclasses (such as one for using 5639 YANG notifications as policy events) need to define how the 5640 iformation from the environment or event is used to populate 5641 variables that can be used by decorator, condition, or 5642 action objects. 5644 6.11.1. SUPAPolicyEvent Attributes 5646 Currently, five attributes are defined for the SUPAPolicyEvent 5647 class, which are described in the following subsections. 5649 6.11.1.1. The Attribute "supaPolicyEventData[1..n]" 5651 This is a mandatory attribute that defines an array of strings. 5652 Each string in the array represents an attribute name and value 5653 of an Event object. The format of each string is defined as 5654 name:value. The 'name' part is the name of the SUPAPolicyEvent 5655 attribute, and the 'value' part is the value of that attribute. 5657 Note: [1..n] means that this is a multi-valued property that has 5658 at least one (and possibly more) attributes. For example, if 5659 this value of this attribute is: 5661 {(startTime:0800), (endTime:1700), (date:2016-05-11), 5662 (timeZone:-08:00)} 5664 then this attribute contains four properties, called startTime, 5665 endTime, date, and timeZone, whose values are 0800, 1700, May 11 5666 2016, and Pacific Standard Time, respectively. 5668 This attribute works with another class attribute, called 5669 supaPolicyEventEncoding, which defines how to interpret this 5670 attribute. These two attributes form a tuple, and together enable 5671 a machine to understand the syntax and value of the data carried 5672 by the object instance of this class. 5674 6.11.1.2. The Attribute "supaPolicyEventEncoding" 5676 This is a mandatory non-zero enumerated integer attribute, and 5677 defines how to interpret the supaPolicyEventData class attribute. 5678 These two attributes form a tuple, and together enable a machine 5679 to understand the syntax and value of the data carried by the 5680 object instance of this class. Values include: 5682 0: error 5683 1: init 5684 2: String 5685 3: Integer 5686 4: Boolean 5687 5: Floating Point 5688 6: DateTime 5689 7: Object referenced by GUID 5690 8: Object referenced by URI 5691 9: Object referenced by FQDN 5692 10: Object referenced by FQPN 5693 11: Object referenced by string_instance_id 5695 Enumerations 0 and 1 signify an error state and an initialization 5696 state, respectively. Enumerations 2-6 define fundamental data types; 5697 for example, the event payload could carry such a value. The final 5698 five enumerations define an object reference. The value 11 defines 5699 the canonical representation, in ASCII, of an instance ID of 5700 this object. 5702 6.11.1.3. The Attribute "supaPolicyEventIsPreProcessed" 5704 This is an optional Boolean attribute. If the value of this 5705 attribute is TRUE, then this SUPAPolicyEvent has been pre- 5706 processed by an external entity, such as an Event Service Bus, 5707 before it was received by the Policy Management System. 5709 6.11.1.4. The Attribute "supaPolicyEventIsSynthetic" 5711 This is an optional Boolean attribute. If the value of this 5712 attribute is TRUE, then this SUPAPolicyEvent has been produced by 5713 the Policy Management System. If the value of this attribute is 5714 FALSE, then this SUPAPolicyEvent has been produced by an entity 5715 in the system being managed. 5717 6.11.1.5. The Attribute "supaPolicyEventTopic[0..n]" 5719 This is a mandatory array of string attributes, and contains the 5720 subject that this PolicyEvent describes. 5722 Note: [0..n] means that this is a multi-valued property that has 5723 zero or more attributes. 5725 6.11.2. SUPAPolicyEvent Relationships 5727 No relationships are currently defined for this class. 5729 6.12. The Concrete Class "SUPAPolicyCondition" 5731 This is a mandatory concrete class that represents the concept of 5732 an Condition that will determine whether or not the set of Actions 5733 in the SUPAECAPolicyRule to which it belongs are executed or not. 5735 Condition clauses needs to be able to access information fromhe 5736 the policy environment (e.g., the network element or policy engine 5737 applying the policy) or the triggering event. This may be done 5738 using SUPAPolicyVariable objects as decorators. If the subclass of 5739 a SUPAPolicyCondition uses some other encoding, the definition of 5740 that class needs to indicate how information from the environment 5741 or event will be used. 5743 SUPAPolicyConditions can be used as part of a SUPAPolicyClause 5744 (e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or as a 5745 standalone SUPAPolicyClause (e.g., the supaPolicyConditionData 5746 attribute contains text that defines the entire condition clause). 5747 This is defined in the supaECACompIsTerm attribute of the 5748 SUPAECAComponent class (see section 6.10). 5750 6.12.1. SUPAPolicyCondition Attributes 5752 Currently, two attributes are defined for the SUPAPolicyCondition 5753 class, which are described in the following subsections. 5755 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 5757 This is a mandatory array of string attributes that contains the 5758 content of this SUPAPolicyCondition object. 5760 Note: [1..n] means that this is a multi-valued property that has 5761 at least one (and possibly more) attributes. 5763 If this class is instantiated, then this attribute SHOULD also be 5764 instantiated, and SHOULD be part of a conformant implementation. 5766 6.12.1.2. The Attribute "supaPolicyConditionEncoding" 5768 This is a mandatory non-zero enumerated integer attribute, and 5769 defines the data type of the supaPolicyConditionData attribute. 5770 These two attributes form a tuple, and together enable a machine 5771 to understand the syntax and value of the content of this 5772 SUPAPolicyCondition object. Values include: 5774 0: error 5775 1: init 5776 2: OCL 2.4 5777 3: OCL 2.x 5778 4: OCL 1.x 5779 5: QVT 1.2 - Relations Language 5780 6: QVT 1.2 - Operational language 5781 7: Alloy 5782 8: ASCII Text 5784 Enumerations 0 and 1 signify an error state and an initialization 5785 state, respectively. Enumerations 2-4 are dedicated to OCL (with 5786 OCL 2.4 being the latest version as of this writing). QVT defines a 5787 set of languages [20] (the two most powerful and useful are defined 5788 by enumerations 5 and 6). Alloy is a language for describing 5789 constraints, and uses a SAT solver to guarantee correctness [21]. 5790 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 5791 and hence, not verifiable), but is included for completeness. 5793 If this class is instantiated, then this attribute SHOULD also be 5794 instantiated, and SHOULD be part of a conformant implementation. 5796 6.12.2. SUPAPolicyCondition Relationships 5798 No relationships are currently defined for this class. 5800 6.13. The Concrete Class "SUPAPolicyAction" 5802 This is a mandatory concrete class that represents the concept of 5803 an Action, which is a part of a SUPAECAPolicyRule. The Action MAY be 5804 executed when both the event and the condition clauses of its 5805 owning SUPAECAPolicyRule evaluate to true. 5807 Action clauses needs to be able to access information fromhe 5808 the policy environment (e.g., the network element or policy engine 5809 applying the policy) or the triggering event. This may be done 5810 using SUPAPolicyVariable objects as decorators. If the subclass of 5811 a SUPAPolicyAction uses some other encoding, the definition of 5812 that class needs to indicate how information from the environment 5813 or event will be used. 5815 The execution of this action is determined by its SUPAPolicy 5816 container, and any applicable SUPAPolicyMetadata objects. 5817 SUPAPolicyActions can be used in three different ways: 5819 o as part of a SUPAPolicyClause (e.g., 5820 var = SUPAPolicyAction.supaPolicyActionData) 5821 o as a standalone SUPAPolicyClause (e.g., the 5822 supaPolicyActionData attribute contains text that defines 5823 the entire action clause) 5824 o to invoke one or more SUPAPolicyActions in a different 5825 SUPAECAPolicyRule 5827 In the third case, the execution semantics should not be affected, 5828 since all SUPAPolicyActions are reusable objects. Note that this is 5829 NOT invoking a different SUPAECAPolicyRule, but rather, invoking a 5830 SUPAPolicyAction that is contained in a different SUPAECAPolicyRule. 5832 6.13.1. Restrictions about SUPAPolicyActions Calling SUPAPolicies 5834 There was confusion as to whether a SUPAPolicyAction could call a 5835 SUPAPolicy or not. While this appears attractive, it presents 5836 several difficult conceptual problems concerning what element has 5837 the scope of control. These problems are not solved in [RFC3460]. 5838 Consider the following scenario: 5840 o Policy A is currently executing 5841 o Action A1 executes successfully 5842 o Action A2 calls Policy B 5843 o Action A3 is either waiting to execute, or is executing 5845 When Policy B is called, it presumably should execute under the 5846 scope of control of Policy A (since Policy A has not finished 5847 executing). However, calling another **ECAPolicyRule** means that 5848 now, the event clause of Policy B should be activated. It is very 5849 difficult to ensure that the next thing the Policy Engine does is 5850 determine if the event clause of B is satisfied or not. 5852 Furthermore, what happens to Action A3? Is Policy B supposed to 5853 finish execution before Action A3? This requires additional logic 5854 (priorities do not work here!), which requires communication 5855 between the policy engine and both Policies A and B. 5857 Even if these problems are solved, what happens if Action A3 fails, 5858 and the supaPolExecFailStrategy has a value of 2 (i.e., if an 5859 action fails, then a rollback must be performed)? Does Policy BCP 5860 also get rolled back? 5862 Therefore, for this version of SUPA, a SUPAPolicyAction can only 5863 call another SUPAPolicyAction. 5865 6.13.2. SUPAPolicyAction Attributes 5867 Currently, two attributes are defined for the SUPAPolicyCondition 5868 class, which are described in the following subsections. 5870 6.13.2.1. The Attribute "supaPolicyActionData[1..n]" 5872 This is a mandatory array of string attributes that contains the 5873 content of this SUPAPolicyAction object. This attribute works with 5874 another class attribute, called supaPolicyActionEncoding, which 5875 defines how to interpret this attribute. 5877 These two attributes form a tuple, and together enable a machine to 5878 understand the syntax and value of the data carried by the object 5879 instance of this class. 5881 Note: [1..n] means that this is a multi-valued property that has 5882 at least one (and possibly more) attributes. 5884 Since this attribute could represent a term in a SUPAPolicyClause 5885 (e.g., var = SUPAPolicyAction.supaPolicyActionData), a complete 5886 SUPAPolicyClause (e.g., the supaPolicyActionData attribute 5887 contains text that defines the entire action clause), or the 5888 name of a SUPAPolicyAction to invoke, each element in the string 5889 array is prepended with one of the following strings: 5891 o 't:' (or 'term:'), to denote a term in a SUPAPolicyClause 5892 o 'c:' (or 'clause:'), to denote an entire SUPAPolicyClause 5893 o 'a:' (or 'action:'), to invoke a SUPAPolicyAction in a 5894 a different SUPAECAPolicyRule 5896 Note that in the third case, the text must identify a unique 5897 SUPAPolicyAction (e.g., the location of the SUPAPolicyAction, 5898 including its containing SUPAPolicy if applicable, MUST be 5899 specified). 5901 6.13.2.2. The Attribute "supaPolicyActionEncoding" 5903 This is a mandatory non-zero enumerated integer attribute, and 5904 defines the data type of the supaPolicyActionData attribute. This 5905 attribute works with another class attribute, called 5906 supaPolicyActionData, which contains the content of the action. 5907 These two attributes form a tuple, and together enable a machine 5908 to understand the syntax and value of the content of this 5909 SUPAPolicyAction object. Values include: 5911 0: error 5912 1: init 5913 2: OCL 2.4 5914 3: OCL 2.x 5915 4: OCL 1.x 5916 5: QVT 1.2 - Relations Language 5917 6: QVT 1.2 - Operational language 5918 7: Alloy 5919 8: ASCII Text 5920 9: GUID 5921 10: UUID 5922 11: URI 5923 12: FQDN 5924 13: FQPN update me 5926 Enumerations 0 and 1 signify an error state and an initialization 5927 state, respectively. Enumerations 2-4 are dedicated to OCL (with 5928 OCL 2.4 being the latest version as of this writing). QVT defines a 5929 set of languages [20] (the two most powerful and useful are defined 5930 by enumerations 5 and 6). Alloy is a language for describing 5931 constraints, and uses a SAT solver to guarantee correctness [21]. 5932 Enumeration 8 (ASCII Text) is not recommended (since it is informal, 5933 and hence, not verifiable), but is included for completeness. 5934 Enumerations 9-12 define a reference to the SUPAPolicyAction. 5936 If this class is instantiated, then this attribute SHOULD also be 5937 instantiated, and SHOULD be part of a conformant implementation. 5939 6.13.3. SUPAPolicyAction Relationships 5941 No relationships are currently defined for this class. It inherits 5942 the relationships defined by the SUPAPolicyComponentDecorator (see 5943 section 5.7.3.). 5945 Enumerations 1-4 are used to provide a reference to an action 5946 object. Enumerations 5-10 are used to express the action to 5947 perform as a string. 5949 7. Examples 5951 This section contains some examples that show how to use various 5952 objects in this draft to build policy rules. 5954 7.1. Example 1: Blocking SNMP Traffic 5956 This example will illustrate how to use the SUPA information model 5957 to block inbound and outbound SNMP traffic. 5959 7.1.1. Introduction 5961 The following exemplar policy was posted to the SUPA list: 5963 ensure that SNMP is blocked on ports at the edgeInterface 5964 of the administrative domain to prevent SNMP going 5965 out or coming in from outside the enterprise. (1) 5967 While this is simple for a human to understand, it is actually 5968 quite difficult for a machine to understand in its original form. 5969 This is because: 5971 1) the text must be translated to a form that the device can 5972 understand 5973 2) the nature of the policy is not clear (due to the inherent 5974 ambiguity of English) 5976 7.1.2. Solution Approach 5978 First, let's assume the following context: 5980 +-----------------------------+ +--------------+ 5981 | Enterprise Domain | | Other Domain | 5982 | | | | 5983 | +-----+ +-----+ +-----+ |/ \| | 5984 | | NE1 | | NE2 | | NE3 +--+-------+ | 5985 | +-----+ +-----+ +-----+ |\ /| | 5986 +-----------------------------+ +--------------+ 5988 In the above example, the only "edge" interface is that of NE3. This 5989 enables us to simplify (1) to: 5991 block SNMP on NE3 (2) 5993 This assumes that NE3 exists and is operational. This is a **big** 5994 assumption. This leads to the observation that in both (1) and (2), 5995 there are at least two different interpretations for each: 5997 1) apply a set of actions directly to a SUPAPolicyTarget, assuming 5998 that the SUPAPolicyTarget understands SUPAPolicies, or 5999 2) apply a set of desired actions that are already translated to 6000 a form that a SUPAPolicyTarget can understand 6002 Note that a SUPAPolicyTarget could be the network device or a proxy 6003 for the network device. 6005 The difference between these interpretations is whether a SUPAPolicy 6006 applies one or more SUPAPolicyActions **directly** to a 6007 SUPAPolicyTarget (that is without translation to, for example, CLI 6008 or YANG) versus whether a SUPAPolicy, as part of its action(s), 6009 produces something that the device (or its proxy) can understand. 6011 Put another way, the first alternative shows how SUPAPolicies can 6012 directly control behavior, while the second alternative shows how a 6013 SUPAPolicy can invoke a set of actions that the device (or its proxy) 6014 can understand. Thus, policy (1) can be formulated as either: 6016 - IF any network element has a port that meets the criterion of 6017 the role "edge interface", AND it is inside the 6018 EnterpriseDomain, then block SNMP traffic (3) 6019 - IF a network element is added within the EnterpriseDomain 6020 IF any of its ports take on the role "edge interface" 6021 Add a filter to block SNMP traffic for that port (4) 6023 The first case is the simplest, and likely what most people thought. 6024 Conceptually, it could look as follows: 6026 Event: SNMP traffic is sent or received 6027 Condition: IF this port implements the "edgeInterface" role 6028 AND IF this port is IN the EnterpriseDomain 6029 Action: Block SNMP traffic (5) 6031 (We will define "edgeInterface" role and "EnterpriseDomain" 6032 later in this note.) 6034 A possible drawback of (5) is that it is activated by the arrival 6035 of a packet event. Such events will be VERY common, meaning that 6036 the Policy Engine will be doing a lot of work when most of the 6037 time, no policy action is needed. 6039 The second case could be addressed as follows: 6041 Event: A new port is going to be enabled 6042 Condition: IF this interface implements the "edgeInterface" 6043 role AND IF this port is IN the EnterpriseDomain 6044 Action: InstallFilter("SNMP traffic filter", "block") (6) 6046 7.1.3. Solution for Case 1 (SUPAPolicies Control Behavior) 6048 This section describes the strategy for, and outlines the steps 6049 taken, to build one exemplar implementation of (5). 6051 7.1.3.1. Strategy 6053 The strategy is to build three clauses, one each to represent the 6054 event, condition, and action clauses of our SUPAECAPolicyRule. These 6055 are realized by three different **objects**, and aggregated by the 6056 SUPAECAPolicyRule (a 4th object) using three different aggregations. 6057 Each aggregation is an instance of SUPAHasPolicyClause. This yields 6058 a structure similar to that in Figure 7 of the SUPA information 6059 model, and is shown below: 6061 C C 6062 +-------------------------+ +----------------------------+/ 6063 | SUPABooleanClauseAtomic | | SUPABooleanClauseComposite +----+ 6064 +-------------+-----------+ +----------+-----------------+\ | 6065 I I | 6066 I I SUPAHasBooleanClause | 6067 +---------------------------+ | 6068 I | 6069 C I | 6070 +-------------------------+ A \ / | 6071 | SUPAECAPolicyRuleAtomic | +------+------------+/ \ | 6072 +-------------+-----------+ | SUPABooleanClause + A ------+ 6073 I +--------+----------+\ / 6074 I I 6075 I I 6076 A \ / A \ / 6077 +--------+----------+ +--------+-----------+ 6078 | SUPAECAPolicyRule | | SUPAPolicyClause | 6079 +--+----+----+------+ +-------+----+----+--+ 6080 / \ / \ / \ 1..n 0..n / \ / \ / \ 6081 A A A | | | 6082 \ / \ / \ / | | | 6083 | | | | | | 6084 | | | SUPAHasPolicyClause #1 | | | 6085 | | +--------------------------+ | | 6086 | | | | 6087 | | SUPAHasPolicyClause #2 | | 6088 | +------------------------------------+ | 6089 | | 6090 | SUPAHasPolicyClause #3 | 6091 +----------------------------------------------+ 6093 Note: all 3 aggregations have a multiplicity of 1..n - 0..n 6095 Figure 29. Creating a SUPAECAPolicyRule 6097 In Figure 29, the event, condition, and action clauses are 6098 represented by the SUPAHasPolicyClause aggregations (#1 - #3). 6099 The association classes for these three aggregations are not shown; 6100 this is because there are no additional semantics required to 6101 define the meaning of each aggregation. This also applies to the 6102 SUPAHasBooleanClause in the top right of the above figure. Finally, 6103 recall that the "I" arrows stand for inheritance. Hence, both the 6104 SUPABooleanClauseAtomic and SUPABooleanClauseComposite classes 6105 inherit from SUPABooleanClause, which inherits from 6106 SUPAPolicyClause. 6108 Another important point to remember in Figure 29 is that classes 6109 inherit both attributes and relationships from their superclasses. 6110 For example, the SUPAECAPolicyRuleAtomic, as well as both the 6111 SUPABooleanClauseAtomic and the SUPABooleanClauseComposite, all 6112 inherit the SUPAHasPolicyClause aggregation. More specifically, the 6113 SUPAECAPolicyRuleAtomic can aggregate SUPAPolicyClauses, and any 6114 type of SUPAPolicyClause can be aggregated by any type of 6115 SUPAPolicyStructure (not shown in the Figures; recall that this is 6116 the superclass of SUPAECAPolicyRule). 6118 The decorator pattern (see Section 4.2.1.2) enables the 6119 SUPAPolicyClause (or any of its concrete subclasses) to be 6120 optionally wrapped by one or more SUPAPolicyComponentDecorator 6121 objects. We will use this feature to adorn the 6122 SUPABooleanPolicyClauseAtomic object with one or more 6123 SUPAPolicyEvent, SUPAPolicyCondition, and SUPAPolicyAction objects. 6125 7.1.3.2. Implementation 6127 Let's build up the representation of (5) using SUPA objects. The 6128 SUPAECAPolicyRule is simple - it is just a SUPAECAPolicyRuleAtomic 6129 object (see Section 6.5). The SUPAECAPolicyRuleAtomic, as opposed to 6130 the SUPAECAPolicyRuleComposite, subclass of SUPAECAPolicyRule is used 6131 because there is no need to create a hierarchy of rules. This means 6132 that there is no need to instantiate the SUPAECAPolicyRuleComposite 6133 class or its SUPAHasECAPolicyRule aggregation for this example. 6135 There are several ways to build SUPAPolicyClauses. The following 6136 will show two different ways to build individual clauses. Our 6137 approach will be to model the event and action clauses as single 6138 SUPABooleanClauseAtomic objects, and then model the condition clause 6139 as a SUPABooleanClauseComposite object. This is just to show how 6140 different parts of the model can be used. 6142 The event clause is a Boolean AND of two values; we choose to 6143 represent it as a textual string (see Section 6.10). 6144 => this means that SUPAECAComponent.supaECACompIsTerm is FALSE 6146 Both events (SNMP inbound and outbound traffic) can be represented 6147 by SUPAPolicyEvents (see Section 6.11) as follows (we are just 6148 showing the inbound event; the outbound event is identical except 6149 that the value of supaPolicyEventData is '{"SNMP outbound"}'): 6150 => supaPolicyEventData is {"SNMP inbound"} 6151 => supaPolicyEventEncoding is 2 // string 6152 => supaPolicyEventIsPreProcessed is FALSE 6153 => supaPolicyEventIsSynthetic is FALSE 6154 => supaPolicyEventTopic is {"SNMP traffic"} 6156 Here, we chose to instantiate all attributes (mandatory and optional) 6157 for the sake of completeness (the first, second, and fifth attributes 6158 are all mandatory). 6160 The condition clause is also a Boolean AND of two values. The first 6161 part of the Boolean clause will test that a device's (sub)-interface 6162 belongs to a Role called edgeInterfaceRole, logically ANDed with it 6163 sending or receiving SNMP traffic. The following two definitions 6164 help clarify the first concept: 6166 - a Role is an abstraction that defines a set of functionality, 6167 behavior, and responsibilities that an object can take on at 6168 any time during its lifecycle. Roles enable the developer to 6169 adapt an object to different client's needs through 6170 transparently attached Role objects, each one representing a 6171 Role the object has to play in that client's context. This 6172 decouples the needs of different applications from each other. 6173 - an "edge interface" is a Role that represents a set of device 6174 (sub)-interfaces that connect two different domains to each 6175 other (e.g., router interfaces that connect the Enterprise 6176 to the Internet). 6178 In this example, the Role is populated by information that is 6179 provided from the received event and/or from the current environment 6180 (e.g., a topology model). 6182 Hence, the first condition clause can be written as: 6184 (((port == 161) OR (port == 162)) AND (interfaceRole == "edge")) 6186 This can be modeled in a variety of ways in SUPA; the simplest is 6187 as a SUPAPolicyCondition (see Section 6.12), as follows: 6188 => SUPAECAComponent.supaECAIsTerm is FALSE 6189 => supaPolicyConditionData is 6190 {"(((port == 161) OR (port == 162)) AND 6191 (interfaceRole == "edge"))"} 6192 => supaPolicyConditionEncoding is 8 // ASCII text 6194 For the second condition clause, we choose to again dramatically 6195 simplify it by mapping "EnterpriseDomain" to a particular IP subnet. 6196 This can also be modeled as a single string in a 6197 SUPAPolicyCondition, as follows: 6198 => SUPAECAComponent.supaECAIsTerm is FALSE 6199 => supaPolicyConditionData is {"IPAddress IN 204.17.5.0/27"} 6200 => supaPolicyConditionEncoding is 8 // ASCII text 6202 Each of the SUPAPolicyCondition objects decorates a separate 6203 instance of a SUPABooleanClauseAtomic object. The three 6204 SUPABooleanClauseAtomic objects are then aggregated by a single 6205 SUPABooleanClauseComposite object (see Section 6.9). This works 6206 because both are concrete subclasses of SUPAPolicyClause, and thus, 6207 both inherit the ability to have objects decorate it. This is shown 6208 in Figure 30: 6210 A 6211 +------------------------------+ 1..n 6212 | SUPAPolicyComponentStructure +----------------------+ 6213 +----------------+-------------+ | 6214 / \ | 6215 I SUPAHasDecoratedPolicyComponent | 6216 I | 6217 +--------------+-----------+ | 6218 I I | 6219 A I A I | 6220 +---------+--------+ +--------------+---------------+ 0..1 | 6221 | | | |/ \ | 6222 | SUPAPolicyClause | | SUPAPolicyComponentDecorator + A -----+ 6223 | | | |\ / 6224 +---------+--------+ +--------------+---------------+ 6225 / \ / \ 6226 I I 6227 A I A I 6228 \+----------+--------+ +---------+--------+ 6229 +----+ SUPABooleanClause | | SUPAECAComponent | 6230 | /+----------+--------+ +---------+--------+ 6231 | / \ / \ 6232 | I I 6233 | I I 6234 | +---+-------+ +----+------+------------+ 6235 | I I I I I 6236 | C I C I C I C I C I 6237 | +---+-----+ +---+----+ +----+---+ +-----+-----+ +----+---+ 6238 | / \| SUPA | | SUPA | | SUPA | | SUPA | | SUPA | 6239 +---- A + Boolean | | Boolean| | Policy | | Policy | | Policy | 6240 \ /| Clause | | Clause | | Event | | Condition | | Action | 6241 |Composite| | Atomic | +--------+ +-----------+ +--------+ 6242 +---------+ +--------+ 6244 Figure 30. Pertinent Classes for Decoration 6246 The three SUPABooleanClauseAtomic objects each have their 6247 supaBoolClauseIsCNF attributes set to TRUE, and their 6248 supaBoolClauseIsNegated attributes set to FALSE. The 6249 supaBoolClauseBindValue attributes of each are: 6251 => 1 for "((port == 161) OR (port == 162))" 6252 => 2 for "(interfaceRole == "edge")" 6253 => 3 for "("IPAddress IN 204.17.5.0/27")" 6255 The first term is shown in Figure X3 below: 6257 C 6258 +--------------------------------------+ 6259 | SUPABooleanClauseAtomic | 6260 | C | 6261 | +----------------------------------+ | 6262 | | SUPAPolicyCondition | | 6263 | | | | 6264 | | ((port == 161) OR (port == 162)) | | 6265 | +----------------------------------+ | 6266 +--------------------------------------+ 6268 Figure 31. Construction of a Condition Clause 6270 Figure 31 represents the SUPAPolicyCondition object wrapping the 6271 SUPABooleanClauseAtomic object (see Section 4.3.5). The combination 6272 of all three SUPABooleanClauseAtomic objects are then aggregated by 6273 a single SUPABooleanClauseComposite object, as shown in Figure 32. 6275 The action clause uses a SUPAPolicyAction (see Section 6.13) 6276 as follows: 6277 => supaPolicyActionData = {"clause: deny"} 6278 => supaPolicyActionEncoding is 8 // ASCII text 6280 7.1.4. Solution for Case 2 (SUPAPolicies Do Not Control Behavior) 6282 This use case is different, in that its objective is to define a 6283 SUPAPolicyAction that is directly readable by a SUPAPolicyTarget. 6284 In this example, our SUPAPolicy will invoke a NetConf operation to 6285 install a new feature (e.g., an ACL for blocking SNMP traffic) for 6286 **any** device whose (sub-)interface takes on the edgeInterface 6287 role and that is transmitting or receiving SNMP traffic. 6289 7.1.4.1. Approach 6291 Once again, we can use a SUPAECAPolicyRuleAtomic object to 6292 represent the SUPAPolicy. This time, we create a new subclass of 6293 SUPAPolicyAction, called SUPAPolicyActionNetConf, which is capable 6294 of executing NetConf operations. 6296 C 6297 +--------------------------------+ 6298 | SUPABooleanClauseComposite | 6299 +----+----------+----------+-----+ 6300 / \ / \ / \ 6301 A A A 6302 \ / \ / \ / 6303 | | | 6304 | | | 6305 | | +------------------+ 6306 C \ / +---------+ | 6307 +--------+----------------+ | | 6308 | SUPABooleanClauseAtomic | | | 6309 | ( port condition ) | | | 6310 +-------------------------+ | | 6311 | | 6312 C \ / | 6313 +------------+------------+ | 6314 | SUPABooleanClauseAtomic | | 6315 | ( interface role ) | | 6316 +-------------------------+ | 6317 | 6318 C \ / 6319 +------------+------------+ 6320 | SUPABooleanClauseAtomic | 6321 | ( IP address ) | 6322 +-------------------------+ 6324 Figure 32. Construction of the Condition Clause 6326 7.1.4.2. Implementation 6328 The SUPAPolicy is again made up of three clauses, one each to 6329 represent the event, condition, and action parts of our 6330 SUPAECAPolicyRule. 6332 The event clause is a simple Boolean clause; the easiest way to 6333 implement it is as a SUPAPolicyEvent (see Section 6.11) as follows: 6334 => supaPolicyEventData is {"enable port"} 6335 => supaPolicyEventEncoding is 2 // string 6336 => supaPolicyEventIsPreProcessed is FALSE 6337 => supaPolicyEventIsSynthetic is FALSE 6338 => supaPolicyEventTopic is {"new port event"} 6340 The condition clause is the same as in section 7.1.3.2. 6342 The action clause is more involved. We want to enable SUPA to 6343 use NetConf operations, so the easiest thing to do is to create a 6344 new subclass of SUPAPolicyAction, called SUPAPolicyActionNetConf. 6346 This is a concrete class, and has the following attributes (more 6347 could be added, of course): 6348 => supaPolNetConfContent 6349 => supaPolNetConfOperation 6350 => supaPolNetConfURL 6352 The supaPolNetConfContent attribute contains an XML document that 6353 will insert (for example) an ACL into the network device (or tell 6354 the proxy for the device to do so). 6356 The supaPolNetConfOperation attribute defines the RPC operation 6357 that will be performed. 6359 The supaPolNetConfURL attribute is an XPath expression that defines 6360 what is being manipulated (in this case, the desired device 6361 interface). 6363 In this example, the SUPAPolicyNetConfOperation will have an XPath 6364 expression that selects the new edge interface. The RPC operation is 6365 responsible for writing the ACL, and the content is the ACL, which 6366 drops traffic on the SNMP UDP ports. 6368 8. Security Considerations 6370 This document defines an object-oriented information model for 6371 describing policy information that is independent of any specific 6372 repository, language, or protocol. This document does not define 6373 any particular system implementation, including a protocol. Hence, 6374 it does not have any specific security requirements. 6376 9. IANA Considerations 6378 This document has no actions for IANA. 6380 10. Contributors 6382 The following people contributed to creating this document, and are 6383 listed in alphabetical order: 6385 Jason Coleman 6387 11. Acknowledgments 6389 This document has benefited from reviews, suggestions, comments 6390 and proposed text provided by the following members, listed in 6391 alphabetical order: Andy Bierman, Bert Wijnen, Bob Natale, Dave 6392 Hood, Fred Feisullin, Georgios Karagiannis, Liu (Will) Shucheng, 6393 Marie-Jose Montpetit. 6395 12. References 6397 This section defines normative and informative references for this 6398 document. 6400 12.1. Normative References 6402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6403 Requirement Levels", BCP 14, RFC 2119, March 1997. 6405 12.2. Informative References 6407 [RFC3060] Moore, B., Ellesson, E., Strassner, J., Westerinen, 6408 A., "Policy Core Information Model -- Version 1 6409 Specification", RFC 3060, February 2001 6411 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 6412 Scherling, M., Quinn, B., Herzog, S., Huynh, A., 6413 Carlson, M., Perry, J., Waldbusser, S., "Terminology 6414 for Policy-Based Management", RFC 3198, November, 2001 6416 [RFC3460] Moore, B., ed., "Policy Core Information Model (PCIM) 6417 Extensions, RFC 3460, January 2003 6419 [1] Strassner, J., "Policy-Based Network Management", 6420 Morgan Kaufman, ISBN 978-1558608597, Sep 2003 6422 [2] Strassner, J., ed., "The DEN-ng Information Model", 6423 add stable URI 6425 [3] Riehle, D., "Composite Design Patterns", Proceedings 6426 of the 1997 Conference on Object-Oriented Programming 6427 Systems, Languages and Applications (OOPSLA '97). 6428 ACM Press, 1997, Page 218-228 6430 [4] DMTF, CIM Schema, v2.44, 6431 http://dmtf.org/standards/cim/cim_schema_v2440 6433 [5] Strassner, J., ed., "ZOOM Policy Architecture and 6434 Information Model Snapshot", TR235, part of the 6435 TM Forum ZOOM project, October 26, 2014 6437 [6] TM Forum, "Information Framework (SID), GB922 and 6438 associated Addenda, v14.5, 6439 https://www.tmforum.org/information-framework-sid/ 6441 [7] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 6442 subtyping", ACM Transactions on Programming languages 6443 and Systems 16 (6): 1811 - 1841, 1994 6445 [8] Klyus, M., Strassner, J., Liu, W., Karagiannis, G., 6446 Bi, J., "SUPA Value Proposition", 6447 draft-klyus-supa-value-proposition-00, March 21, 2016 6449 [9] ISO/IEC 10746-3 (also ITU-T Rec X.903), "Reference 6450 Model Open Distributed Processing Architecture", 6451 April 20, 2010 6453 [10] Davy, S., Jennings, B., Strassner, J., "The Policy 6454 Continuum - A Formal Model", Proc. of the 2nd Intl. 6455 IEEE Workshop on Modeling Autonomic Communication 6456 Environments (MACE), Multicon Lecture Notes, No. 6, 6457 Multicon, Berlin, 2007, pages 65-78 6459 [11] Gamma, E., Helm, R., Johnson, R., Vlissides, J., 6460 "Design Patterns - Elements of Reusable Object-Oriented 6461 Software", Addison-Wesley, 1994, ISBN 0-201-63361-2 6463 [12] Strassner, J., de Souza, J.N., Raymer, D., Samudrala, 6464 S., Davy, S., Barrett, K., "The Design of a Novel 6465 Context-Aware Policy Model to Support Machine-Based 6466 Learning and Reasoning", Journal of Cluster Computing, 6467 Vol 12, Issue 1, pages 17-43, March, 2009 6469 [13] http://csrc.nist.gov/projects/iden_ac.html 6471 [14] Martin, R.C., "Agile Software Development, Principles, 6472 Patterns, and Practices", Prentice-Hall, 2002, 6473 ISBN: 0-13-597444-5 6475 [15] Halpern, J., Strassner, J., "Generic Policy Data Model 6476 for Simplified Use of Policy Abstractions (SUPA)" 6477 draft-ietf-supa-generic-policy-data-model-03, 6478 April 15, 2017 6480 [16] Wang, Y., Esposito, F., Matta, I., Day, J., "RINA: An 6481 Architecture for Policy-based Dynamic Service 6482 Management", Tech Report BUCS-TR-2013-014, 2013 6484 [17] Meyer, B., "Object-Oriented Software Construction", 6485 Prentice Hall, second edition, 1997 ISBN 0-13-629155-4 6487 [18] http://semver.org/ 6489 [19] ISO/IEC:2004(E), "Data elements and interchange 6490 formats -- Information interchange -- Representation 6491 of dates and times", 2004 6493 [20] http://www.omg.org/spec/QVT/ 6495 [21] http://alloy.mit.edu/alloy/ 6497 [22] Basile, C., and Lioy, A., "Analysis of Application- 6498 Layer Filtering Policies with Application to HTTP", 6499 IEEE/ACM Transactions on Networking, Vol 23, Issue 1, 6500 February 2015 6502 [23] van Lunteren, J., and Engbersen, T., "Fast and Scalable 6503 Packet Classification", IEEE Journal on Selected Areas 6504 in Communication, vol 21, Issue 4, September 2003 6506 [24] perldoc.perl.org 6508 [25] ISO/IEC/IEEE 9945, "Information technology - Portable 6509 Operating System Interface (POSIX) Base Specifications, 6510 Issue 7", September, 2009 6512 Authors' Addresses 6514 John Strassner 6515 Huawei Technologies 6516 2330 Central Expressway 6517 Santa Clara, CA 95138 USA 6518 Email: john.sc.strassner@huawei.com 6520 Joel Halpern 6521 Ericsson 6522 P. O. Box 6049 6523 Leesburg, VA 20178 6524 Email: joel.halpern@ericsson.com 6526 Sven van der Meer 6527 LM Ericsson Ltd. 6528 Ericsson Software Campus 6529 Garrycastle 6530 Athlone 6531 N37 PV44 6532 Ireland 6533 Email: sven.van.der.meer@ericsson.com 6535 Appendix A. Brief Analyses of Previous Policy Work 6537 This appendix describes of some of the important problems with 6538 previous IETF policy work., and describes the rationale for 6539 taking different design decisions in this document. 6541 A.1. PolicySetComponent vs. SUPAPolicyStructure 6543 The ability to define different types of policy rules is not 6544 present in [RFC3060] and [RFC3460], because both are based on [4], 6545 and this ability is not present in [4]. [RFC3060], [RFC3460], and 6546 [4] are all limited to CA (condition-action) policy rules. In 6547 addition, events are NOT defined. These limitations mean that 6548 RFC3060], [RFC3460], and [4] can only represent CA Policy Rules. 6550 In contrast, the original design goal of SUPA was to define a 6551 single class hierarchy that could represent different types of 6552 policies (e.g., imperative and declarative). Hence, it was 6553 decided to make SUPAPolicyStructure generic in nature, so that 6554 different types of policies could be defined as subclasses. This 6555 enables a single Policy Framework to support multiple types of 6556 policies. 6558 A.2. Flat Hierarchy vs. SUPAPolicyComponentStructure 6560 Figure 32 shows a portion of the class hierarchy of [RFC3460]. 6562 A 6563 +--------+ 6564 | Policy | 6565 +----+---+ 6566 / \ 6567 | 6568 | 6569 +---------+------+------+------------+-----------+ 6570 | | | | | 6571 A | | A | | A | 6572 +-----+-----+ | +--------+--------+ | +------+-------+ 6573 | PolicySet | | | PolicyCondition | | | PolicyAction | 6574 +-----+-----| | +--------+--------+ | +------+-------+ 6575 / \ | / \ | / \ 6576 | | | | | 6577 ... | ... | ... 6578 A | A | 6579 +-------+--------+ +-------+-----+ 6580 | PolicyVariable | | PolicyValue | 6581 +-------+--------+ +-------+-----+ 6582 / \ / \ 6583 | | 6584 ... ... 6586 Figure 32. Simplified Class Hierarcy of [RFC3460] 6588 RFC3060], [RFC3460], and [4] defined PolicyConditions and 6589 PolicyActions as subclasses of Policy (along with PolicySet, 6590 which is the superclass of PolicyRules and PolicyGroups). This 6591 means that there is no commonality between PolicyConditions and 6592 PolicyActions, even though they are both PolicyRule components. 6593 From an object-oriented point-of-view, this is incorrect, since a 6594 PolicyRule aggregates both PolicyConditions and PolicyActions. 6596 In addition, note that both PolicyVariables and PolicyValues are 6597 siblings of PolicyRules, PolicyConditions, and PolicyActions. This 6598 is incorrect for several reasons: 6600 o a PolicyRule cannot rectly contain PolicyVariables or 6601 PolicyValues, so they shouldn't be at the same level of the 6602 class hierarchy 6603 o both PolicyConditions and PolicyActions can contain 6604 PolicyVariables and PolicyValues, which implies that both 6605 PolicyVariables and PolicyValues should be lower in the 6606 class hierarchy 6608 Note that in the current version of [4], PolicyVariable and 6609 PolicyValue are both deleted. There are other changes as well, 6610 but they are beyond the scope of this Appendix. 6612 The original design goal of SUPA was to define a single class 6613 hierarchy that could represent different types of policies and 6614 policy components. This cannot be accomplished in [RFC3460], since 6615 there is no notion of a policy component (or alternatively, 6616 PolicyCondition, PolicyAction, PolicyVariable, and PolicyValue are 6617 all components at the same abstraction level, which is clearly not 6618 correct). Hence, SUPA defined the SUPAPolicyComponentStructure 6619 class to capture the concept of a reusable policy component. 6621 In summary, SUPAPolicyStructure subclasses define the structure of 6622 a policy in a common way, while SUPAPolicyComponentStructure 6623 subclasses define the content that is contained in the structure 6624 of a policy, also in a common way. 6626 A.3. PolicyRules and PolicyGroups vs. SUPAPolicyRules 6628 A PolicySetComponent is an aggregation, implemented as an 6629 association class, that "collects instances of PolicySet 6630 subclasses into coherent sets of Policies". This is a recursive 6631 aggregation, with multiplicity 0..n - 0..n, on the PolicySet 6632 class. 6634 Since this is a recursive aggregation, it means that a PolicySet 6635 can aggregate zero or more PolicySets. This is under-specified, 6636 and can be interpreted in one of two ways: 6638 1. A PolicySet subclass can aggregate any PolicySet subclass 6639 (PolicyRules can aggregate PolicyRules and PolicyGroups, and 6640 vice-versa) 6641 2. PolicyRules can aggregate PolicyRules, and PolicyGroups can 6642 aggregate PolicyGroups, but neither class can aggregate the 6643 other type of class 6645 Both interpretations are ill-suited for policy-based management. 6646 The problem with the first is that if PolicyGroup is the mechanism 6647 for grouping, why can a PolicyRule aggregate a PolicyGroup? This 6648 implies that PolicyGroups are not needed. The problem with the 6649 second is that PolicyGroups cannot aggregate PolicyRules (which 6650 again implies that PolicyGroups are not needed). 6652 Furthermore, there are no mechanisms defined in the [RFC3460] 6653 model to prevent loops of PolicyRules. This is a problem, because 6654 EVERY PolicyRule and PolicyGroup inherits this recursive 6655 aggregation. 6657 This is why this document uses the composite pattern. First, this 6658 pattern clearly shows what object is aggregating what other 6659 object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate a 6660 SUPAECAPolicyRuleComposite). Second, it does not allow a 6661 SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule 6662 (this is discussed more in the following subsection). 6664 A.3.1. Sub-rules 6666 Sub-rules (also called nested policy rules) enable a policy rule to 6667 be contained within another policy rule. These have very complex 6668 semantics, are very hard to debug, and provide limited value. They 6669 also require a complex set of aggregations (see section A.4.). 6671 The main reason for defining sub-rules in [RFC3460] is to enable 6672 "complex policy rules to be constructed from multiple simpler 6673 policy rules". However, the composite pattern does this much more 6674 efficiently than a simple recursive aggregation, and avoids the 6675 ambiguous semantics of a recursive aggregation. This latter point 6676 is important, because if PolicyRule and/or PolicyGroup is 6677 subclassed, then all subclasses still inherit this recursive 6678 aggregation, along with its ambiguous semantics. 6680 A.4. PolicyConditions and PolicyActions vs. SUPAECAComponent 6682 There is no need to use the SimplePolicyCondition and 6683 ComplexPolicyCondition objects defined in [RFC3460], since the 6684 SUPAPolicyComponentStructure uses the decorator pattern (see 6685 section 5.7) to provide more extensible types of conditions than is 6686 possible with those classes. This also applies for the 6687 SimplePolicyAction and the ComplexPolicyAction classes defined in 6688 [RFC3460]. 6690 More importantly, this removes the need for a complex set of 6691 aggregations (i.e., PolicyComponent, PolicySetComponent, 6692 PolicyConditionStructure, PolicyConditionInPolicyRule, 6693 PolicyConditionInPolicyCondition, PolicyActionStructure, 6694 PolicyActionInPolicyRule, and PolicyActionInPolicyAction). 6695 Instead, ANY SUPAECAComponent is defined as a decorator (i.e., a 6696 subclass of SUPAPolicyComponentDecorator), and hence, Any 6697 SUPAECAComponent is wrapped onto a concrete subclass of 6698 SUPAPolicyClause using the SAME aggregation 6699 (SUPAHasDecoratedPolicyComponent). This is a significantly simpler 6700 design that is also more powerful. 6702 A.5. The SUPAPolicyComponentDecorator Abstraction 6704 One of the problems in building a policy model is the tendency to 6705 have a multitude of classes, and hence object instances, to 6706 represent different combinations of policy events, conditions, and 6707 actions. This can lead to class and/or relationship explosion, as 6708 is the case in [RFC3460], [4], and [6]. 6710 For example, [RFC3460] defines five subclasses of PolicyCondition: 6711 PolicyTimePeriodCondition, VendorPolicyCondition, 6712 SimplePolicyCondition, CompoundPolicyCondition, and 6713 CompoundFilterCondition. Of these: 6715 o PolicyTimePeriodCondition is a data structure, not a class 6716 o VendorPolicyCondition represents a condition using two 6717 attributes that represent a multi-valued octet string 6718 o SimplePolicyCondition, CompoundPolicyCondition, and 6719 CompoundFilterCondition all have ambiguous semantics 6721 SimplePolicyCondition represents an ordered 3-tuple, in the form 6722 {variable, match, value}. However, the match operator is not 6723 formally modeled. Specifically, "the 'match' relationship is to 6724 be interpreted by analyzing the variable and value instances 6725 associated with the simple condition". This becomes problematic 6726 for several cases, such as shallow vs. deep object comparisons. 6727 More importantly, this requires two separate aggregations 6728 (PolicyVariableInSimplePolicyCondition and 6729 PolicyValueInSimplePolicyCondition) to associate variables and 6730 values to the SimplePolicyCondition, respectively. Since [RFC3460] 6731 defines all relationships as classes, this means that the 6732 expression "Foo > Bar" requires a total of FIVE objects (one each 6733 for the variable and value, one for the SimplePolicyCondition, and 6734 one each to associate the variable and value with the 6735 SimplePolicyCondition). 6737 This is exacerbated when SimplePolicyConditions are used to build 6738 CompoundPolicyConditions. In addition to the above complexity 6739 (which is required for each SimplePolicyCondition), a new 6740 aggregation (PolicyConditionInPolicyCondition) is required to 6741 aggregation PolicyConditions. Thus, the compound expression: 6742 "((Foo > Bar) AND (Foo < Baz))" requires a total of THIRTEEN 6743 objects (five for each of the terms being ANDed, plus one for the 6744 CompoundPolicyCondition, and two to aggregate each term to the 6745 CompoundPolicyCondition). 6747 Note that in the above examples, the superclasses of each of the 6748 relationships are omitted for clarity. In addition, [RFC3460] is 6749 built using inheritance; this means that if a new function is 6750 required, a new class must be built (e.g., CompoundFilterCondition 6751 is a subclass, but all it adds is one attribute). 6753 In constrast, the Decorator Pattern enables behavior to be 6754 selectively added to an individual object, either statically or 6755 dynamically, without having to build association classes. In 6756 addition, the decorator pattern uses composition, instead of 6757 inheritance, to avoid class explosion. This means that a new 6758 variable, value, or even condition class can be defined at 6759 runtime, and then all or part of that class can dynamically wrap 6760 an existing object without need for recompilation and 6761 redeployment. 6763 A.6. The Abstract Class "SUPAPolicyClause" 6765 This abstraction is missing in [RFC3060], [RFC3460], [4], and [6]. 6766 SUPAPolicyClause was abstracted from DEN-ng [2], and a version of 6767 this class is in the process of being added to [5]. However, the 6768 class and relationship design in [5] differs significantly from 6769 the corresponding designs in this document. 6771 SUPAPolicyClause further reinforces the different between a policy 6772 rule and a component of a policy rule by abstracting the content 6773 of a policy rule as a reusable object. This is fundamental for 6774 enabling different types of policy rules (e.g., imperative and 6775 declarative) to to be represented using the same constructs. 6777 A.7. Problems with the RFC3460 Version of PolicyVariable 6779 The following subsections define a brief, and incomplete, set of 6780 problems with the implementation of [RFC3460] (note that [RFC3060 6781 did not define variables, operators, and/or values). 6783 A.7.1. Object Bloat 6785 [RFC3460] used two different and complex mechanisms for providing 6786 generic get and set expressions. PolicyVariables were subclassed 6787 into two subclasses, even though they performed the same semantic 6788 function. This causes additional problems: 6790 o PolicyExplicitVariables are for CIM compatibility; note that 6791 the CIM does not contain either PolicyVariables or 6792 PolicyValues ([4]) 6793 o PolicyImplicitVariable subclasses do not define attributes; 6794 rather, they are bound to an appropriate subclass of 6795 PolicyValue using an association 6797 Hence, defining a variable is relatively expensive in [RFC3460], 6798 as in general, two objects and an association must be used. The 6799 objects themselves do not define content; rather, their names are 6800 used as a mechanism to identify an object to match. This means 6801 that an entire object must be used (instead of, for example, an 6802 attribute), which is wasteful. It also make it difficult to 6803 adjust constraints at runtime, since the constraint is defined in 6804 a class that is statically defined (and hence, requires 6805 recompilation and possibly redeployment if it is changed). 6807 A.7.2. Object Explosion 6809 The above three problems lead to class explosion (recall that in 6810 [RFC3060], [RFC3460], and [4], associations are implemented as 6811 classes). 6813 In contrast to this approach, the approach in this document keeps 6814 the idea of the class hierarchy for backwards compatibility, but 6815 streamlines the implementation. Specifically: 6817 1. The decorator pattern is an established and very used 6818 software pattern (it dates back to at least 1994 [11]). 6819 2. The use of a single association class 6820 (i.e., SUPAHasDecoratedPolicyComponentDetail) can represent 6821 more constraints than is possible in the approaches of 6822 [RFC3460] and [4] in a much more flexible manner, due to its 6823 function as a decorator of other objects. 6824 3. Note that there is no way to enforce the constraint matching 6825 in [RFC3460] and [6]; the burden is on the developer to 6826 check and see if the constraints specified in one class are 6827 honored in the other class. 6828 4. If these constraints are not honored, there is no mechanism 6829 specified to define the clause as incorrectly formed. 6831 A.7.3. Specification Ambiguities 6833 There are a number of ambiguities in [RFC3460]. 6835 First, [RFC3460] says: "Variables are used for building individual 6836 conditions". While this is true, variables can also be used for 6837 building individual actions. This is reflected in the definition 6838 for SUPAPolicyVariable. 6840 Second, [RFC3460] says: "The variable specifies the property of a 6841 flow or an event that should be matched when evaluating the 6842 condition." While this is true, variables can be used to test many 6843 other things than "just" a flow or an event. This is reflected in 6844 the SUPAPolicyVariable definition. 6846 Third, the [RFC3460] definition requires the use of associations 6847 in order to properly constrain the variable (e.g., define its 6848 data type, the range of its allowed values, etc.). This is both 6849 costly and inefficient. 6851 Fourth, [RFC3460] is tightly bound to the DMTF CIM schema [4]. 6852 The CIM is a data model (despite its name), because: 6854 o It uses keys and weak relationships, which are both concepts 6855 from relational algebra and thus, not technology-independent 6856 o It has its own proprietary modeling language 6857 o It contains a number of concepts that are not defined in UML 6858 (including overriding keys for subclasses) 6860 Fifth, the class hierarchy has two needless classes, called 6861 SUPAImplicitVariable and SUPAExplicitVariable. These classes do 6862 not define any attributes or relationships, and hence, do not 6863 add any semantics to the model. 6865 Finally, in [RFC3460], defining constraints for a variable is 6866 limited to associating the variable with a PolicyValue. This is 6867 both cumbersome (because associations are costly; for example, 6868 they equate to a join in a relational database management system), 6869 and not scalable, because it is prone to proliferating PolicyValue 6870 classes for every constraint (or range of constraints) that is 6871 possible. Therefore, in SUPA, this mechanism is replaced with 6872 using an association to an association class that defines 6873 constraints in a much more general and powerful manner (i.e., 6874 the SUPAHasDecoratedPolicyComponentDetail class). 6876 A.8. Problems with the RFC3460 Version of PolicyValue 6878 The following subsections define a brief, and incomplete, set of 6879 problems with the implementation of [RFC3460] (note that [RFC3060 6880 did not define variables, operators, and/or values). 6882 A.8.1. Object Bloat 6884 [RFC3460] defined a set of 7 subclasses; three were specific to 6885 networking (i.e., IPv4 Address, IPv6 Address, MAC Address) and 4 6886 (PolicyStringValue, PolicyBitStringValue, PolicyIntegerValue, and 6887 PolicyBooleanValue) were generic in nature. However, each of these 6888 objects defined a single class attribute. This has the same two 6889 problems as with PolicyVariables (see section 5.9.1.1): 6891 1. Using an entire object to define a single attribute is very 6892 wasteful and expensive 6893 2. It also make it difficult to adjust constraints at runtime, 6894 since the constraint is defined in a class that is statically 6895 defined (and hence, requires recompilation and possibly 6896 redeployment if it is changed). 6898 A.8.2. Object Explosion 6900 [RFC3460] definition requires the use of associations 6901 in order to properly constrain the variable (e.g., define its 6902 data type, the range of its allowed values, etc.). This is both 6903 costly and inefficient (recall that in [RFC3060], [RFC3460], and 6904 [4], associations are implemented as classes). 6906 A.8.3. Lack of Constraints 6908 There is no generic facility for defining constraints for a 6909 PolicyValue. Therefore, there is no facility for being able to 6910 change such constraints dynamically at runtime. 6912 A.8.4. Tightly Bound to the CIM Schema 6914 [RFC3460] is tightly bound to the DMTF CIM schema [4]. The CIM is 6915 a data model (despite its name), because: 6917 o It uses keys and weak relationships, which are both concepts 6918 from relational algebra and thus, not technology-independent 6919 o It has its own proprietary modeling language 6920 o It contains a number of concepts that are not defined in UML 6921 (including overriding keys for subclasses) 6923 A.8.5. Specification Ambiguity 6925 [RFC3460] says: It is used for defining values and constants used 6926 in policy conditions". While this is true, variables can also be 6927 used for building individual actions. This is reflected in the 6928 SUPAPolicyVariable definition. 6930 A.8.6. Lack of Symmetry 6932 Most good information models show symmetry between like components. 6933 [RFC3460] has no symmetry in how it defines variables and values. 6934 In contrast, this document recognizes that variables and values 6935 are just terms in a clause; hence, the only difference in the 6936 definition of the SUPAPolicyVariable and SUPAPolicyValue classes 6937 is that the content attribute in the former is a single string, 6938 whereas the content attribute in the latter is a string array. 6939 In particular, the semantics of both variables and values are 6940 defined using the decorator pattern, along with the attributes of 6941 the SUPAPolicyComponentDecorator and the 6942 SUPAHasDecoratedPolicyComponentDetail classes.