idnits 2.17.1 draft-strassner-supa-generic-policy-info-model-04.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 934 has weird spacing: '... Policy fro...' -- The document date (February 12, 2016) is 2989 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2460' is mentioned on line 5465, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Unused Reference: 'RFC6020' is defined on line 5080, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 5084, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3198 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-02) exists of draft-klyus-supa-proposition-01 Summary: 4 errors (**), 0 flaws (~~), 7 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: August 17, 2016 Ericsson 5 J. Coleman 6 Cisco Systems 7 February 12, 2016 9 Generic Policy Information Model for 10 Simplified Use of Policy Abstractions (SUPA) 11 draft-strassner-supa-generic-policy-info-model-04 13 Abstract 15 This document defines an information model for representing 16 policies using a common extensible framework that is independent 17 of language, protocol, repository. It is also independent of the 18 level of abstraction of the content and meaning of a policy. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current 28 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 This Internet-Draft will expire on August 17, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided 51 without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Overview ....................................................... 9 56 1.1. Introduction .............................................. 9 57 1.2. Changes Since Version -03 ................................ 11 58 2. Conventions Used in This Document ............................. 11 59 3. Terminology ................................................... 12 60 3.1. Acronyms .................................................. 12 61 3.2. Definitions ............................................... 12 62 3.2.1. Core Terminology ..................................... 12 63 3.2.1.1. Information Model .............................. 12 64 3.2.1.2. Data Model ..................................... 13 65 3.2.1.3. Abstract Class ................................. 13 66 3.2.1.4. Concrete Class ................................. 13 67 3.2.1.5. Container ...................................... 13 68 3.2.1.6. 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 .............................. 14 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 .................................... 16 81 3.2.3.4. Aggregation .................................... 16 82 3.2.3.5. Composition .................................... 17 83 3.2.3.6. Association Class .............................. 17 84 3.2.3.7. Multiplicity ................................... 17 85 3.2.3.8. Navigability ................................... 17 86 3.3. Symbology ................................................ 18 87 3.3.1. Inheritance ......................................... 18 88 3.3.2. Association ......................................... 18 89 3.3.3. Aggregation ......................................... 19 90 3.3.4. Composition ......................................... 19 91 3.3.5. Association Class ................................... 19 92 3.3.6. Abstract vs. Concrete Classes ....................... 20 93 4. Policy Abstraction Architecture ............................... 21 94 4.1. Motivation ............................................... 22 95 4.2. SUPA Approach ............................................ 23 97 Table of Contents (continued) 99 4.3. SUPA Generic Policy Information Model Overview............ 23 100 4.3.1. SUPAPolicyObject .................................... 25 101 4.3.2. SUPAPolicyStructure ................................. 26 102 4.3.3. SUPAPolicyComponentStructure ........................ 26 103 4.3.4. SUPAPolicyClause .................................... 27 104 4.3.5. SUPAPolicyComponentDecorator ........................ 27 105 4.3.6. SUPAPolicyTarget .................................... 28 106 4.3.7. SUPAPolicySource .................................... 28 107 4.4. The Design of the GPIM ................................... 28 108 4.4.1. Structure of Policies ............................... 29 109 4.4.2. Representing an ECA Policy Rule ..................... 30 110 4.4.3. Creating SUPA Policy Clauses ........................ 33 111 4.4.4. Creating SUPAPolicyClauses .......................... 36 112 4.4.5. SUPAPolicySources ................................... 37 113 4.4.6. SUPAPolicyTargets ................................... 39 114 4.4.7. SUPAPolicyMetadata .................................. 39 115 4.4.7.1. Motivation ..................................... 39 116 4.4.7.2. Design Approach ................................ 40 117 4.4.7.2.1. Policies and Actors ....................... 42 118 4.4.7.2.2. Deployment vs. Execution of Policies ...... 43 119 4.4.7.2.3. Using SUPAMetadata for Policy Deployment 120 and Execution ............................. 43 121 4.4.7.3. Structure of SUPAPolicyMetadata ................ 44 122 4.5. Advanced Features ........................................ 47 123 4.5.1. Policy Grouping ..................................... 47 124 4.5.2. Policy Rule Nesting ................................. 47 125 5. GPIM Model ..................................................... 48 126 5.1. Overview .................................................. 48 127 5.2. The Abstract Class "SUPAPolicyObject" ..................... 49 128 5.2.1. SUPAPolicyObject Attributes .......................... 50 129 5.2.1.1. Object Identifiers ............................. 50 130 5.2.1.2. The Attribute "supaPolObjIDContent" ............. 51 131 5.2.1.3. The Attribute "supaPolObjIDEncoding" ............ 51 132 5.2.1.4. The Attribute "supaPolicyDescription" ........... 51 133 5.2.1.5. The Attribute "supaPolicyName" .................. 51 134 5.2.2. SUPAPolicy Relationships ............................ 52 135 5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 52 136 5.2.2.2. The Association Class 137 "SUPAHasPolicyMetadataDetail" .................. 52 138 5.3. The Abstract Class "SUPAPolicyStructure" ................. 52 139 5.3.1. SUPAPolicyStructure Attributes ...................... 53 140 5.3.1.1. The Attribute "supaPolAdminStatus" ............. 53 141 5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 53 142 5.3.1.3. The Attribute "supaPolDeployStatus" ............ 54 143 5.3.1.4. The Attribute "supaPolExecStatus" .............. 54 144 5.3.1.5. The Attribute "supaPolExecFailStrategy" ........ 54 146 Table of Contents (continued) 148 5.3.2. SUPAPolicyStructure Relationships ................... 55 149 5.3.2.1. The Aggregation "SUPAHasPolicySource" .......... 55 150 5.3.2.2. The Association Class 151 "SUPAHasPolicySourceDetail" .................... 55 152 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" . 55 153 5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" ....... 56 154 5.3.2.3. The Aggregation "SUPAHasPolicyTarget" .......... 56 155 5.3.2.4. The Association Class 156 "SUPAHasPolicyTargetDetail" ................... 56 157 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" . 56 158 5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" ....... 56 159 5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" . 57 160 5.3.2.6. The Association Class 161 "SUPAHasPolExecFailTakeActionDetail" ........... 57 162 5.3.2.6.1. The Attribute 163 "supaPolExecFailTakeActionEncoding" ....... 57 164 5.3.2.6.2. The Attribute 165 "supaPolExecFailTakeActionName[1..n]" ..... 58 166 5.3.2.7. The Aggregation "SUPAHasPolicyClause" .......... 58 167 5.3.2.8. The Association Class 168 "SUPAHasPolicyClauseDetail" .................... 58 169 5.4. The Abstract Class "SUPAPolicyComponentStructure" ........ 59 170 5.4.1. SUPAPolicyComponentStructure Attributes ............. 59 171 5.4.2. SUPAPolicyComponentStructure Relationships .......... 59 172 5.5. The Abstract Class "SUPAPolicyClause" .................... 59 173 5.5.1. SUPAPolicyClause Attributes ......................... 60 174 5.5.1.1. The Attribute "supaPolClauseExecStatus" ........ 60 175 5.5.2. SUPAPolicyClause Relationships ...................... 61 176 5.6. The Concrete Class "SUPAEncodedClause" ................... 61 177 5.6.1. SUPAEncodedClause Attributes ........................ 61 178 5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 61 179 5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 61 180 5.6.1.3. The Attribute "supaEncodedClauseResponse" ...... 62 181 5.6.2. SUPAEncodedClause Relationships ..................... 62 182 5.7. The Abstract Class "SUPAPolicyComponentDecorator" ........ 62 183 5.7.1. The Decorator Pattern ............................... 63 184 5.7.2. SUPAPolicyComponentDecorator Attributes ............. 64 185 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 64 186 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 64 187 5.7.3. SUPAPolicyComponentDecorator Relationships .......... 65 188 5.7.3.1. The Aggregation 189 "SUPAHasDecoratedPolicyComponent" .............. 65 190 5.7.3.2. The Association Class 191 "SUPAHasDecoratedPolicyComponentDetail" ........ 65 192 5.7.3.2.1. The Attribute 193 "supaDecoratedConstraintEncoding" ......... 65 194 5.7.3.2.2. The Attribute 195 "supaDecoratedConstraint[0..n]" ........... 66 196 5.7.4. Illustration of Constraints in the Decorator Pattern 66 198 Table of Contents (continued) 200 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 67 201 5.8.1. SUPAPolicyTerm Attributes ........................... 68 202 5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 68 203 5.8.2. SUPAPolicyTerm Relationships ........................ 68 204 5.9. The Concrete Class "SUPAPolicyVariable" .................. 68 205 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 69 206 5.9.2. SUPAPolicyVariable Attributes ....................... 69 207 5.9.2.1. The Attribute "supaPolVarName" ................. 69 208 5.9.3. SUPAPolicyVariable Relationships .................... 69 209 5.10. The Concrete Class "SUPAPolicyOperator" ................. 69 210 5.10.1. Problems with the RFC3460 Version .................. 70 211 5.10.2. SUPAPolicyOperator Attributes ...................... 70 212 5.10.2.1. The Attribute "supaPolOpType" ................. 70 213 5.10.3. SUPAPolicyOperator Relationships ................... 70 214 5.11. The Concrete Class "SUPAPolicyValue" .................... 71 215 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 71 216 5.11.2. SUPAPolicyValue Attributes ......................... 71 217 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 71 218 5.11.2.2. The Attribute "supaPolValEncoding" ............ 72 219 5.11.3. SUPAPolicyValue Relationships ...................... 72 220 5.12. The Concrete Class "SUPAVendorDecoratedComponent" ....... 72 221 5.12.1. SUPAVendorDecoratedComponent Attributes ............ 73 222 5.12.1.1. The Attribute 223 "supaVendorDecoratedCompContent[0..n]" ......... 73 224 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 73 225 5.12.2. SUPAVendorDecoratedComponent Relationships ......... 73 226 5.13. The Concrete Class "SUPAPolicyCollection" ............... 74 227 5.13.1. Motivation ......................................... 74 228 5.13.2. Solution ........................................... 74 229 5.13.3. SUPAPolicyCollection Attributes .................... 75 230 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 75 231 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 75 232 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 75 233 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 75 234 5.13.3.5. The Attribute "supaPolCollectionType" ......... 76 235 5.13.4. SUPAPolicyCollection Relationships ................. 77 236 5.14. The Concrete Class "SUPAPolicySource" ..................... 77 237 5.14.1. SUPAPolicySource Attributes ........................ 77 238 5.14.2. SUPAPolicySource Relationships ..................... 77 239 5.15. The Concrete Class "SUPAPolicyTarget" ................... 77 240 5.15.1. SUPAPolicyTarget Attributes ........................ 78 241 5.15.2. SUPAPolicyTarget Relationships ..................... 78 243 Table of Contents (continued) 245 5.16. The Abstract Class "SUPAPolicyMetadata" ................. 78 246 5.16.1. SUPAPolicyMetadata Attributes ...................... 79 247 5.16.1.1. The Attribute "supaPolMetadataDescription" .... 79 248 5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 79 249 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 79 250 5.16.1.4. The Attribute "supaPolMetadataName" ........... 80 251 5.16.2. SUPAPolicyMetadata Relationships ................... 80 252 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 80 253 5.16.2.2. The Abstract Class 254 "SUPAHasPolicyMetadataDetail" ................. 80 255 5.16.2.2.1. The Attribute 256 "supaPolMetadataIsApplicable" ............ 80 257 5.16.2.2.2. The Attribute 258 "supaPolMetadataConstraintEncoding" ...... 81 259 5.16.2.2.3. The Attribute 260 "supaPolMetadataConstraint[0..n]" ........ 81 261 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 81 262 5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 82 263 5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 82 264 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 82 265 5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 82 266 5.18.1.1. The Attribute "supaPolMDValidPeriodEnd" ....... 82 267 5.18.1.2. The Attribute "supaPolMDValidPeriodStart" ..... 82 268 5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 82 269 5.18.2.1. The Aggregation "HasSUPAMetadataDecorator" .... 83 270 5.18.2.2. The Association Class 271 "HasSUPAMetadataDecoratorDetail" .............. 83 272 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 83 273 5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 84 274 5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 84 275 5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 84 276 5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 85 277 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 85 278 5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 85 279 5.20.1.1. The Attribute "supaVersionMajor" .............. 85 280 5.20.1.2. The Attribute "supaVersionMinor" .............. 86 281 5.20.1.3. The Attribute "supaVersionRelType" ............ 86 282 5.20.1.4. The Attribute "supaVersionTypeNum" ............ 86 283 6. SUPA ECAPolicyRule Information Model .......................... 87 284 6.1. Overview ................................................. 87 285 6.2. Constructing a SUPAECAPolicyRule ......................... 88 286 6.3. Working With SUPAECAPolicyRules .......................... 89 287 6.4. The Abstract Class "SUPAECAPolicyRule" ................... 91 288 6.4.1. SUPAECAPolicyRule Attributes ........................ 92 289 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 93 290 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ........ 93 291 6.4.2. SUPAECAPolicyRule Relationships ..................... 93 293 Table of Contents (continued) 295 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 93 296 6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 93 297 6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 93 298 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 94 299 6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 94 300 6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 94 301 6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 95 302 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 95 303 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 95 304 6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 95 305 6.7. The Abstract Class "SUPABooleanClause" ................... 96 306 6.7.1. SUPABooleanClause Attributes ........................ 96 307 6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 97 308 6.7.2. SUPABooleanClause Relationships ..................... 97 309 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............. 97 310 6.8.1. SUPABooleanClauseAtomic Attributes .................. 97 311 6.8.2. SUPABooleanClauseAtomic Relationships ............... 97 312 6.9. The Concrete Class "SUPABooleanClauseComposite" .......... 97 313 6.9.1. SUPABooleanClauseComposite Attributes ................ 98 314 6.9.1.1. The Attribute "supaBoolClauseBindValue" ........ 98 315 6.9.1.2. The Attribute "supaBoolClauseIsCNF" ............ 98 316 6.9.2. SUPABooleanClauseComposite Relationships ............ 98 317 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ......... 98 318 6.9.3. The Concrete Class "SUPAHasBooleanClauseDetail" ..... 99 319 6.9.3.1. SUPAHasBooleanClauseDetail Attributes .......... 99 320 6.10. The Abstract Class "SUPAECAComponent" ................... 99 321 6.10.1. SUPAECAComponent Attributes ........................ 99 322 6.10.1.1. The Attribute supaECACompIsTerm .............. 100 323 6.10.2. SUPAECAComponent Relationships .................... 100 324 6.11. The Concrete Class "SUPAPolicyEvent" ................... 100 325 6.11.1. SUPAPolicyEvent Attributes ........................ 100 326 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 100 327 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 100 328 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 101 329 6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 101 330 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 101 331 6.11.2. SUPAPolicyEvent Relationships ..................... 101 332 6.12. The Concrete Class "SUPAPolicyCondition" ............... 102 333 6.12.1. SUPAPolicyCondition Attributes .................... 102 334 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 102 335 6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 102 336 6.12.2. SUPAPolicyEvent Relationships ..................... 102 337 6.13. The Concrete Class "SUPAPolicyAction" .................. 103 338 6.13.1. SUPAPolicyAction Attributes ....................... 103 339 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 103 340 6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 104 341 6.13.2. SUPAPolicyAction Relationships .................... 104 343 7. Examples ...................................................... 104 344 8. Security Considerations ...................................... 104 345 9. IANA Considerations ........................................... 105 346 10. Acknowledgments .............................................. 105 347 11. References ................................................... 105 348 11.1. Normative References .................................... 105 349 11.2. Informative References ................................. 105 350 Authors' Addresses ............................................... 107 351 Appendix A. Brief Analyses of Previous Policy Work .............. 107 352 Appendix B. Mathematical Logic Terminology and Symbology ........ 114 353 Appendix C. SUPA Logic Statement Information Model .............. 114 354 1. Overview 356 This document defines an information model for representing 357 policies using a common extensible framework that is independent 358 of language, protocol, repository, and the level of abstraction of 359 the content and meaning of a policy. This enables a common set of 360 concepts defined in this information model to be mapped into 361 different representations of policy (e.g., procedural, imperative, 362 and declarative). It also enables different data models that use 363 different languages, protocols, and repositories to optimize 364 their usage. The definition of common policy concepts also 365 provides better interoperability by ensuring that each data 366 model can share a set of common concepts, independent of its 367 level of detail or the language, protocol, and/or repository 368 that it is using. It is also independent of the target data 369 model that will be generated. 371 This version of the information model focuses on defining one 372 type of policy rule: the event-condition-action (ECA) policy rule. 373 Accordingly, this document defines two sets of model elements: 375 1. A framework for defining the concept of policy, 376 independent of how policy is represented or used; this is 377 called the SUPA Generic Policy Information Model (GPIM) 378 2. A framework for defining a policy model that uses the 379 event-condition-action paradigm; this is called the SUPA 380 Eca Policy Rule Information Model (EPRIM), and extends 381 concepts from the GPIM. 383 The combination of the GPIM and the EPRIM provides an extensible 384 framework for defining policy that uses an event-condition-action 385 representation that is independent of data repository, data 386 definition language, query language, implementation language, and 387 protocol. 389 The Appendices describe how the structure of the GPIM defines a 390 set of generic concepts that enables other types of policies, such 391 as declarative (or "intent-based") policies, to be added later. 393 1.1. Introduction 395 Simplified Use of Policy Abstractions (SUPA) defines an interface 396 to a network management function that takes high-level, possibly 397 network-wide policies as input and creates element configuration 398 snippets as output. SUPA addresses the needs of operators and 399 application developers to represent multiple types of policy 400 rules, which vary in the level of abstraction, to suit the needs 401 of different actors [1], [10]. 403 Different constituencies of users would like to use languages that 404 use terminology and concepts that are familiar to each constituency. 405 Rather than require multiple software systems to be used for each 406 language, a common information model enables these different 407 languages to be mapped to terms in the information model. This 408 facilitiates the use of a single software system to generate data 409 models for each language. In the example shown in Figure 1 (which 410 is a simplified policy continuum [10]), each constituency needs 411 different grammars using different concepts and terminologies to 412 match their skill set. This is shown in Figure 1. A unified 413 information model is one way to build a consensual lexicon that 414 enables terms from one language to be mapped to terms of another 415 language. 417 +---------------------+ 418 +---------------+ \| High-level Policies | \+-------------+ 419 | Business User |----| Without Technical |----| Language #1 | 420 +---------------+ /| Terminology | /+-------------+ 421 +---------------------+ 423 +---------------------+ 424 +---------------+ \| Policies That Use | \+-------------+ 425 | Developer |----| Classes, Attributes,|----| Language #2 | 426 +---------------+ /| Relationships, ... | /+-------------+ 427 +---------------------+ 429 ... ... ... 431 +---------------------+ 432 +---------------+ \| Low-level Policies | \+-------------+ 433 | Admin |----| with Technology- |----| Language #n | 434 +---------------+ /| Specific Terms in a | /+-------------+ 435 | Specific Language | 436 +---------------------+ 438 Figure 1. Different Constituencies Need Different Policies 440 More importantly, an information model defines concepts in a 441 uniform way, enabling formal mapping processes to be developed to 442 translate the information model to a set of data models. This 443 simplifies the process of constructing software to automate the 444 policy management process. It also simplifies the language 445 generation process, though that is beyond the scope of this 446 document. 448 This common framework takes the form of an information model that 449 is divided into one high-level module and any number of lower- 450 level modules, where each lower-level module extends the concepts 451 of the single high-level module. Conceptually, a set of model 452 elements (e.g., classes, attributes, and relationships) are used 453 to define the Generic Policy Information Model (GPIM); this module 454 defines a common set of policy management concepts that are 455 independent of the type of policy (e.g., imperative, procedural, 456 declarative, or otherwise). Then, any number of additional modules 457 are derived from the GPIM; each additional module MUST extend the 458 GPIM to define a new type of policy rule by adding to the GPIM. 459 (Note: using extensions preserves the core interoperability, as 460 compared with modification of the base GPIM, which would adversely 461 compromise interoperability. 463 The SUPA Eca Policy Rule Information Model (EPRIM) extends the 464 GPIM to represent policy rules that use the Event-Condition-Action 465 (ECA) paradigm. (The Appendices describe the SUPA Logic Statement 466 Information Model (LSIM), which shows how to extend the GPIM to 467 represent a collection of statements that are either Propositional 468 Logic (PL) or First-Order Logic (FOL), respectively. Both of these 469 logics are types of declarative logic. Note that the LSIM is 470 currently out of scope. However, it is outlined as a set of 471 Appendices in this document to get feedback on its utility. 473 1.2. Changes Since Version -03 475 There are several main changes in this version of this document 476 compared to the previous versions of this document. They are: 478 1) The GPIM has been redesigned to be more compact, making it 479 easier to construct data models. Additional optimizations 480 have been done to make it easier to translate to YANG 481 2) As part of 1), additional options for constructing data 482 models have been added to the GPIM 483 3) The multiplicity of all relationships have been fine-tuned 484 4) The LSIM has been moved into an Appendix, since the latest 485 charter makes it currently out of scope. However, it is 486 important to ensure that the GPIM can serve as a single 487 foundation that different types of policies can all be 488 derived from to ensure that SUPA can interact with other 489 SDOs, as well as for future work in the IETF. 490 5) Examples and figures have been added to clarify the model 492 2. Conventions Used in This Document 494 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 495 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 496 this document are to be interpreted as described in [RFC2119]. In 497 this document, these words will appear with that interpretation 498 only when in ALL CAPS. Lower case uses of these words are not to 499 be interpreted as carrying [RFC2119] significance. 501 3. Terminology 503 This section defines acronyms, terms, and symbology used in the 504 rest of this document. 506 3.1. Acronyms 508 CLI Command Line Interface 509 CRUD Create, Read, Update, Delete 510 CNF Conjunctive Normal Form 511 DNF Disjunctive Normal Form 512 ECA Event-Condition-Action 513 EPRIM (SUPA) ECA Policy Rule Information Model 514 GPIM (SUPA) Generic Policy Information Model 515 NETCONF Network Configuration protocol 516 OAM&P Operations, Administration, Management, and Provisioning 517 OID Object IDentifier 518 PAP Policy Administration Point 519 PDP Policy Decision Point 520 PEP Policy Enforcement Point 521 PIP Policy Information Point 522 PR Policy Repository 523 PXP Policy Execution Point 524 SUPA Simplified Use of Policy Abstractions 525 TMF TeleManagent Forum (TM Forum) 526 UML Unified Modeling Language 527 URI Uniform Resource Identifier 528 YANG A data definition language for use with NETCONF 529 ZOOM Zero-touch Orchestration, Operations, and Management 530 (a TMF project that also works on information models) 532 3.2. Definitions 534 This section defines the terminology that is used in this document. 536 3.2.1. Core Terminology 538 The following subsections define the terms "information model" and 539 "data model", as well as "container" and "policy container". 541 3.2.1.1. Information Model 543 An information model is a representation of concepts of interest 544 to an environment in a form that is independent of data repository, 545 data definition language, query language, implementation language, 546 and protocol. 548 Note: this definition is more specific than that of [RFC3198], so 549 as to focus on the properties of information models. 551 3.2.1.2. Data Model 553 A data model is a representation of concepts of interest to an 554 environment in a form that is dependent on data repository, data 555 definition language, query language, implementation language, and 556 protocol (typically, but not necessarily, all three). 558 Note: this definition is more specific than that of [RFC3198], so 559 as to focus on the properties of data models that are generated 560 from information models. 562 3.2.1.3. Abstract Class 564 An abstract class is a class that cannot be directly instantiated. 565 It MAY have abstract or concrete subclasses. It is denoted with a 566 capital A near the top-left side of the class. 568 3.2.1.4. Concrete Class 570 A concrete class is a class that can be directly instantiated. Note 571 that classes are either abstract or concrete. In addition, once a 572 class has been defined as concrete in the hierarchy, all of its 573 subclasses MUST also be concrete. It is denoted with a capital C 574 near the top-left side of the class. 576 3.2.1.5. Container 578 A container is an object whose instances may contain zero or more 579 additional objects, including container objects. A container 580 provides storage, query, and retrieval of its contained objects 581 in a well-known, organized way. 583 3.2.1.6. PolicyContainer 585 In this document, a PolicyContainer is a special type of container 586 that provides at least the following three functions: 588 1. It uses metadata to define how its content is interpreted 589 2. It separates the content of the policy from the 590 representation of the policy 591 3. It provides a convenient control point for OAMP operations 593 The combination of these three functions enables a PolicyContainer 594 to define the behavior of how its constituent components will be 595 accessed, queried, stored, retrieved, and how they operate. 597 This document does NOT define a specific data type to implementation 598 a PolicyContainer, as many different types of data types can be 599 used. However, the data type chosen SHOULD NOT allow duplicate 600 members in the PolicyContainer. In addition, order is irrelevant, 601 since priority will override any initial order of the members of 602 this PolicyContainer. 604 3.2.2. Policy Terminology 606 The following terms define different policy concepts used in the 607 SUPA Generic Policy Information Model (GPIM). Note that the 608 prefix "SUPA" is used for all classes and relationships defined 609 in this model to ensure name uniqueness. Similarly, the prefix 610 "supa" is defined for all SUPA class attributes. 612 3.2.2.1. SUPAPolicyObject 614 A SUPAPolicyObject is the root of the GPIM class hierarchy. It is 615 an abstract class that all classes inherit from, except the 616 SUPAPolicyMetadata class. 618 3.2.2.2. SUPAPolicy 620 A SUPAPolicy is, in this version of this document, an ECA policy 621 rule that is a type of PolicyContainer. The PolicyContainer MUST 622 contain an ECA policy rule, SHOULD contain one or more 623 SUPAPolicyMetadata objects, and MAY contain other elements that 624 define the semantics of the policy rule. Policies are generically 625 defined as a means to monitor and control the changing and/or 626 maintaining of the state of one or more managed objects [1]. In 627 this context, "manage" means that at least create, read, query, 628 update, and delete functions are supported. 630 3.2.2.3. SUPAPolicyClause 632 A SUPAPolicyClause is an abstract class. Its subclasses define 633 different types of clauses that are used to create the content 634 for different types of SUPAPolicies. 636 For example, the SUPABooleanClause subclass models the content 637 of a SUPAPolicy as a Boolean clause, where each Boolean clause 638 is made up of a set of reusable objects. In contrast, a 639 SUPAEncodedClause encodes the entire clause as a set of 640 attributes. All types of SUPAPolicies MUST use one or more 641 SUPAPolicyClauses to construct a SUPAPolicy. 643 3.2.2.4. SUPAECAPolicyRule 645 An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an 646 abstract class that is a type of PolicyContainer. It represents 647 a policy rule as a three-tuple, consisting of an event, a 648 condition, and an action clause. In an information model, this 649 takes the form of three different aggregations, one for each 650 clause. Each clause MUST be represented by at least one 651 SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain 652 zero or more SUPAPolicySources, zero or more SUPAPolicyTargets, 653 and zero or more SUPAPolicyMetadata objects. 655 3.2.2.5. SUPAMetadata 657 Metadata is, literally, data about data. SUPAMetadata is an 658 abstract class that contains prescriptive and/or descriptive 659 information about the object(s) to which it is attached. While 660 metadata can be attached to any information model element, this 661 document only considers metadata attached to classes and 662 relationships. 664 When defined in an information model, each instance of the 665 SUPAMetadata class MUST have its own aggregation relationship 666 with the set of objects that it applies to. However, a data model 667 MAY map these definitions to a more efficient form (e.g., 668 flattening the object instances into a single object instance). 670 3.2.2.6. SUPAPolicyTarget 672 SUPAPolicyTarget is an abstract class that defines a set of 673 managed objects that may be affected by the actions of a 674 SUPAPolicyClause. A SUPAPolicyTarget may use one or more 675 mechanisms to identify the set of managed objects that it 676 affects; examples include OIDs and URIs. 678 When defined in an information model, each instance of the 679 SUPAPolicyTarget class MUST have its own aggregation 680 relationship with each SUPAPolicy that uses it. However, a 681 data model MAY map these definitions to a more efficient form 682 (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and 683 SUPAPolicy object instances into a single object instance). 685 3.2.2.7. SUPAPolicySource 687 SUPAPolicySource is an abstract class that defines a set of 688 managed objects that authored this SUPAPolicyClause. This is 689 required for auditability. A SUPAPolicySource may use one or more 690 mechanisms to identify the set of managed objects that authored it; 691 examples include OIDs and URIs. Specifically, policy CRUD MUST be 692 subject to authentication and authorization, and MUST be auditable. 693 Note that the mechanisms for doing these three operations are 694 currently not included, and are for further discussion. 696 When defined in an information model, each instance of the 697 SUPAPolicySource class MUST have its own aggregation relationship 698 with each SUPAPolicy that uses it. However, a data model MAY map 699 these definitions to a more efficient form (e.g., flattening the 700 SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances 701 into a single object instance). 703 3.2.3. Modeling Terminology 705 The following terms define different types of relationships used 706 in the information models of the SUPA Generic Policy Information 707 Model (GPIM). 709 3.2.3.1. Inheritance 711 Inheritance makes an entity at a lower level of abstraction (e.g., 712 the subclass) a type of an entity at a higher level of abstraction 713 (e.g., the superclass). Any attributes and relationships that are 714 defined for the superclass are also defined for the subclass. 715 However, a subclass does NOT change the characteristics or behavior 716 of the attributes or relationships of the superclass that it 717 inherits from. Formally, this is called the Liskov Substitution 718 Principle [7]. This principle is one of the key characteristics 719 that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. 721 A subclass MAY add new attributes and relationships that refine 722 the characteristics and/or behavior of it compared to its 723 superclass. A subclass MUST NOT change inherited attributes or 724 relationships. 726 3.2.3.2. Relationship 728 A relationship is a generic term that represents how a first set 729 of entities interact with a second set of entities. A recursive 730 relationship sets the first and second entity to the same entity. 731 There are three basic types of relationships, as defined in the 732 subsections below: associations, aggregations, and compositions. 734 A subclass MUST NOT change the multiplicity (see section 3.2.3.7) 735 of a relationship that it inherits. A subclass MUST NOT change any 736 attributes of a relation that it inherits that is realized using 737 an association class (see section 3.2.3.6). 739 3.2.3.3. Association 741 An association represents a generic dependency between a first 742 and a second set of entities. In an information model, an 743 association MAY be represented as a class. 745 3.2.3.4. Aggregation 747 An aggregation is a stronger type (i.e., more restricted 748 semantically) of association, and represents a whole-part 749 dependency between a first and a second set of entities. Three 750 objects are defined by an aggregation: the first entity, the 751 second entity, and a new third entity that represents the 752 combination of the first and second entities. 754 The entity owning the aggregation is referred to as the 755 "aggregate", and the entity that is aggregated is referred to as 756 the "part". In an information model, an aggregation MAY be 757 represented as a class. 759 3.2.3.5. Composition 761 A composition is a stronger type (i.e., more restricted 762 semantically) of aggregation, and represents a whole-part 763 dependency with two important behaviors. First, an instance of the 764 part is included in at most one instance of the aggregate at a 765 time. Second, any action performed on the composite entity (i.e., 766 the aggregate) is propagated to its constituent part objects. 767 For example, if the composite entity is deleted, then all of its 768 constituent part entities are also deleted. This is not true of 769 aggregations or associations - in both, only the entity being 770 deleted is actually removed, and the other entities are unaffected. 771 In an information model, a composition MAY be represented as 772 a class. 774 3.2.3.6. Association Class 776 A relationship may be implemented as an association class. This is 777 used to define the relationship as having its own set of features. 778 More specifically, if the relationship is implemented as an 779 association class, then the attributes of the association class, as 780 well as other relationships that the association class participates 781 in, may be used to define the semantics of the relationship. If the 782 relationship is not implemented as an association class, then no 783 additional semantics (beyond those defined by the type of the 784 relationship) are expressed by the relationship. 786 3.2.3.7. Multiplicity 788 A specification of the range of allowable cardinalities that a set 789 of entities may assume. This is always a pair of ranges, such as 790 1 - 1 or 0..n - 2..5. 792 3.2.3.8. Navigability 794 A relationship may have a restriction on the ability of an object 795 at one end of the relationship to access the object at the other 796 end of the relationship. This document defines two choices: 798 1. Each object is navigable by the other, which is indicated 799 by NOT providing any additional symbology, or 801 2. An object A can navigate to object B, but object B cannot 802 navigate to object A. This is indicated by an open-headed 803 arrow pointing to the object that cannot navigate to the 804 other object. In this example, the arrow would be pointing 805 at object B. 807 Examples of navigability are: 809 +---------+ 3..4 +---------+ 810 | | 1..2 \| | 811 | Class A |--------------| Class B | 812 | | /| | 813 +---------+ +---------+ 815 This is an association. Class A can navigate to Class B, but Class 816 B cannot navigate to Class A. This is a mandatory association, 817 since none of the multiplicities contain a '0'. This association 818 reads as follows: 820 Class A depends on 3 to 4 instances of Class B, and 821 Class B depends on 1 to 2 instances of Class A. 823 3.3. Symbology 825 The following symbology is used in this document: 827 3.3.1. Inheritance 829 Inheritance: a subclass inherits the attributes and relationships 830 of its superclass, as shown below: 832 +------------+ 833 | Superclass | 834 +------+-----+ 835 / \ 836 I 837 I 838 I 839 +------+-----+ 840 | Subclass | 841 +------------+ 843 3.3.2. Association 845 Association: Class B depends on Class A, as shown below: 847 +---------+ +---------+ 848 +---------+ +---------+ | | \| | 849 | Class A |------| Class B | | Class A |------| Class B | 850 +---------+ +---------+ | | /| | 851 +---------+ +---------+ 853 association with no association with 854 navigability restrictions navigability restrictions 856 3.3.3. Aggregation 858 Aggregation: Class B is the part, Class A is the aggregate, 859 as shown below: 861 +---------+ +---------+ +---------+ 862 | |/ \ +---------+ | |/ \ \| | 863 | Class A | A ---| Class B | | Class A | A ------| Class B | 864 | |\ / +---------+ | |\ / /| | 865 +---------+ +---------+ +---------+ 867 aggregation with no aggregation with 868 navigability restrictions navigability restrictions 870 3.3.4. Composition 872 Composition: Class B is the part, Class A is the composite, 873 as shown below: 875 +---------+ +---------+ +---------+ 876 | |/ \ +---------+ | |/ \ \| | 877 | Class A | C ---| Class B | | Class A | C ------| Class B | 878 | |\ / +---------+ | |\ / /| | 879 +---------+ +---------+ +---------+ 881 composition with no composition with 882 navigability restrictions navigability restrictions 884 3.3.5. Association Class 886 Association Class: Class C is the association class implementing 887 the relationship D between classes A and B 888 +---------+ +---------+ 889 | Class A |----+-----| Class B | 890 +---------+ ^ +---------+ 891 | 892 | 893 +----------+----------+ 894 | Association Class C | 895 +---------------------+ 897 3.3.6. Abstract vs. Concrete Classes 899 In UML, abstract classes are denoted with their name in italics. 900 For this draft, a capital 'A' will be placed at either the top 901 left or right corner of the class to signify that the class is 902 abstract. Similarly, a captial 'C' will be placed in the same 903 location to represent a concrete class. This is shown below. 905 A C 906 +---------+ +---------+ 907 | Class A | | Class B | 908 +---------+ +---------+ 910 An Abstract Class A Concrete Class 912 4. Policy Abstraction Architecture 914 This section describes the motivation for the policy abstractions 915 that are used in SUPA. The following abstractions are provided: 917 o The GPIM defines a technology-neutral information model that 918 can express the concept of Policy. 919 o All classes, except for SUPAPolicyMetadata, inherit from 920 SUPAPolicyObject, or one of its subclasses 921 o SUPAPolicyObject and SUPAPolicyMetadata are designed to 922 inherit from classes in another model; the GPIM does not 923 define an "all-encompassing" model. 924 o This version of this document restricts the expression of 925 Policy to a set of event-condition-action clauses. 926 o Each clause is defined as a Boolean expression, and is a 927 reusable object 928 o Clauses may be combined to form more complex Boolean 929 expressions 930 o The purpose of the GPIM is to enable different policies that 931 have fundamentally different representations to share common 932 model elements. Policy statmeents, which are implemented as 933 instances of the SUPAPolicyClause class, separates the content 934 of a Policy from its representation. This is supported by: 935 o All policy rules (of which SUPAECAPolicyRule is the 936 first example of a concrete class) are derived from 937 the SUPAPolicyStructure class. 938 o All objects that are components of policy rules are 939 derived from the SUPAPolicyComponentStructure class. 940 o A SUPAPolicy MUST contain at least one SUPAPolicyClause. 941 o A SUPAPolicy MAY specify one or more SUPAPolicyTarget, 942 SUPAPolicySource, and SUPAPolicyMetadata objects to 943 augment the semantics of the SUPAPolicy 944 o A SUPAPolicyClause has two subclasses: 945 o A SUPABooleanClause, which is used to build 946 SUPAECAPolicyRules from reusable objects. 947 o A SUPAEncodedClause, which is used for using 948 attributes instead of objects to construct a 949 SUPAECAPolicyRule. 950 o A SUPAECAPolicyRule defines the set of events and conditions 951 that are responsible for executing its actions; it MUST have 952 at least one event clause, at least one condition clause, and 953 at least one action clause. 954 o The action(s) of a SUPAECAPolicyRule are ONLY executed 955 if both the event and condition clauses evaluate to TRUE 956 o A SUPAPolicyAction MAY invoke another SUPAECAPolicyRule 957 (see section 6.13). 958 o SUPAMetadata MAY be defined for any SUPAPolicyObject class. 959 o SUPAMetadata MAY be prescriptive and/or descriptive in nature. 961 Please see the Appendices for experimental definitions of 962 declarative policies. Note that they also are derived from the 963 GPIM, and extend (but do not change) the above abstractions. 965 4.1. Motivation 967 The power of policy management is its applicability to many 968 different types of systems. There are many different actors that 969 can use a policy management system, including end-users, operators, 970 application developers, and administrators. Each of these 971 constituencies have different concepts and skills, and use 972 different terminology. For example, an operator may want to express 973 an operational rule that states that only Platinum and Gold users 974 can use streaming multimedia applications. As a second example, a 975 network administrator may want to define a more concrete policy 976 rule that looks at the number of dropped packets and, if that 977 number exceeds a programmable threshold, changes the queuing and 978 dropping algorithms used. 980 SUPA may be used to define other types of policies, such as for 981 systems and operations management; an example is: "All routers and 982 switches must have password login disabled". See section 3 of [8] 983 for additional declarative and ECA policy examples. 985 All of the above examples are commonly referred to as "policy 986 rules", but they take very different forms, since they are at very 987 different levels of abstraction and typically authored by 988 different actors. The first was very abstract, and did not contain 989 any technology-specific terms, while the second was more concrete, 990 and likely used technical terms of a general (e.g., IP address 991 range, port numbers) as well as a vendor-specific nature (e.g., 992 specific queuing, dropping, and/or scheduling algorithms 993 implemented in a particular device). The third restricted the type 994 of login that was permissible for certain types of devices in the 995 environment. 997 Note that the first two policy rules could directly affect each 998 other. For example, Gold and Platinum users might need different 999 device configurations to give the proper QoS markings to their 1000 streaming multimedia traffic. This is very difficult to do if a 1001 common policy model does not exist, especially if the two policies 1002 are authored by different actors that use different terminology 1003 and have different skill sets. More importantly, the users of 1004 these two policies likely have different job responsibilities. 1005 They may have no idea of the concepts used in each policy. Yet, 1006 their policies need to interact in order for the business to 1007 provide the desired service. This again underscores the need for 1008 a common policy framework. 1010 Certain types of policy rules (e.g., ECA) may express actions, or 1011 other types of operations, that contradict each other. SUPA 1012 provides a rich object model that can be used to support language 1013 definitions that can find and resolve such problems. 1015 4.2. SUPA Approach 1017 The purpose of the SUPA Generic Policy Information Model (GPIM) is 1018 to define a common framework for expressing policies at different 1019 levels of abstraction. SUPA uses the GPIM as a common vocabulary 1020 for representing policy concepts that are independent of language, 1021 protocol, repository, and level of abstraction. This enables 1022 different actors to author and use policies at different levels of 1023 abstraction. This forms a policy continuum [1] [2], where more 1024 abstract policies can be translated into more concrete policies, 1025 and vice-versa. 1027 Most systems define the notion of a policy as a single entity. 1028 This assumes that all users of policy have the same terminology, 1029 and use policy at the same level of abstraction. This is rarely, 1030 if ever, true in modern systems. The policy continuum defines a 1031 set of views (much like RM-ODP's viewpoints [9]) that are each 1032 optimized for a user playing a specific role. SUPA defines the 1033 GPIM as a standard vocabulary and set of concepts that enable 1034 different actors to use different formulations of policy. This 1035 corresponds to the different levels in the policy continuum, and 1036 as such, can make use of previous experience in this area. 1038 It may be necessary to translate a Policy from a general to a more 1039 specific form (while keeping the abstraction level the same). For 1040 example, the declarative policy "Every network attached to a VM 1041 must be a private network owned by someone in the same group as 1042 the owner of the VM" may be translated to more formal form (e.g., 1043 Datalog (as in OpenStack Congress). It may also be necessary to 1044 translate a Policy to a different level of abstraction. For 1045 example, the previous Policy may need to be translated to a form 1046 that network devices can process directly. This requires a common 1047 framework for expressing policies that is independent of the level 1048 of abstraction that a Policy uses. 1050 4.3. SUPA Generic Policy Information Model Overview 1052 Figure 2 illustrates the approach for representing policy rules 1053 in SUPA. The top two layers are defined in this document; the 1054 bottom layer (Data Models) are defined in separate documents. 1055 Conceptually, the GPIM defines a set of objects that define the 1056 key elements of a Policy independent of how it is represented or 1057 its content. As will be shown, there is a significant difference 1058 between SUPAECAPolicyRules (see Section 6) and other types of 1059 policies (see Section 7). In principle, other types of SUPAPolicies 1060 could be defined, but the current charter is restricted to using 1061 only event-condition-action SUPAPolicies as exemplars. 1063 +----------------------------------------------+ 1064 | SUPA Generic Policy Information Model (GPIM) | 1065 +----------------------+-----------------------+ 1066 / \ 1067 | 1068 | 1069 +-----------------+--------------+ 1070 | | 1071 | | 1072 +-----------+---------------+ +-------------+-------------+ 1073 | SUPAECAPolicyRule | | Other Policy Models that | 1074 | Information Model (EPRIM) | | are Derived from the GPIM | 1075 +-----------+---------------+ +-------------+-------------+ 1076 / \ / \ 1077 | | 1078 | | 1079 +-----------+-----------+ +-----------+------------+ 1080 | ECAPolicyRule | | Other Types of | 1081 | Data Model | | Data Models | 1082 +-----------------------+ +------------------------+ 1084 Figure 2. Overview of SUPA Policy Rule Abstractions 1086 This draft defines the GPIM and EPRIM. Note that there is only 1087 ONE GPIM and ONE EPRIM. While both can be extended, it is 1088 important to limit the number of information models to one, in 1089 order to avoid defining conflicting concepts at this high a 1090 level of abstraction. Similarly, if the GPIM and EPRIM are part 1091 of another information model, then they should collectively 1092 still define a single information model. The GPIM defines the 1093 following concepts: 1095 o A class defining the top of the GPIM class hierarchy, called 1096 SUPAPolicyObject 1097 o Four subclasses of SUPAPolicyObject, representing: 1098 o the top of the PolicyRule hierarchy, called 1099 SUPAPolicyStructure 1100 o the top of the PolicyRule component hierarchy, called 1101 SUPAPolicyComponentStructure 1102 o PolicySource 1103 o PolicyTarget 1105 The SUPAPolicyStructure class is the superclass for all types of 1106 Policies (e.g., imperative, declarative, and others). This 1107 document is currently limited to imperative (e.g., ECA) policies. 1108 However, care has been taken to ensure that the attributes and 1109 relationships of the SUPAPolicyStructure class are extensible, 1110 and can be used for more types of policies than just ECA policies. 1112 This yields the following high-level structure: 1114 A 1115 +------------------+ 1116 | SUPAPolicyObject | 1117 +--------+---------+ 1118 / \ 1119 I 1120 I 1121 +----------------+--------------------+ 1122 I I I 1123 A I I A I 1124 +--------+------------+ I +------------+-----------------+ 1125 | SUPAPolicyStructure | I | SUPAPolicyComponentStructure | 1126 +----+----------------+ I +------------+-----------------+ 1127 / \ I / \ 1128 I +--------+----+ I 1129 I I I I 1130 I C I I I 1131 I +-------+----------+ I I 1132 I | SUPAPolicySource | I I 1133 I +------------------+ I I 1134 I I I 1135 I +-------------+ I 1136 I I I 1137 I C I +-----+-------+ 1138 I +-------+----------+ I I 1139 I | SUPAPolicyTarget | A I I 1140 I +------------------+ +--------+---------+ I 1141 A I | SUPAPolicyClause | I 1142 +-----+------------+ +------------------+ I 1143 | SUPAECAPolicyRule| I 1144 +------------------+ A I 1145 +--------------------+---------+ 1146 | SUPAPolicyComponentDecorator | 1147 +------------------------------+ 1149 Figure 3. Functional View of the Top-Level GPIM 1151 Note that all classes except the SUPAPolicySource and the 1152 SUPAPolicyTarget classes are defined as abstract. This provides 1153 more freedom for the data modeler in implementing the data model. 1154 For example, if the data model uses an object-oriented language, 1155 such as Java, then the above structure enables all of the abstract 1156 classes to be collapsed to a single concrete class. If this is 1157 done, attributes as well as relationships are inherited. 1159 4.3.1. SUPAPolicyObject 1161 A SUPAPolicyObject serves as a single root of the SUPA system 1162 (i.e., all other classes in the model are subclasses of the 1163 SUPAPolicyObject class). This simplifes code generation and 1164 reusability. It also enables SUPAPolicyMetadata objects to be 1165 attached to any appropriate subclass of SUPAPolicyObject. 1167 4.3.2. SUPAPolicyStructure 1169 SUPAPolicyStructure is an abstract superclass that is the base 1170 class for defining different types of policies (however, in this 1171 version of this document, only ECA policy rules are modeled). It 1172 serves as a convenient aggregation point to define atomic (i.e., 1173 individual policies that can be used independently) and composite 1174 (i.e., hierarchies of policies) SUPAPolicies; it also enables 1175 PolicySources and/or PolicyTargets to be associated with a given 1176 set of Policies. 1178 SUPAPolicies are defined as either a stand-alone PolicyContainer 1179 or a hierarchy of PolicyContainers. A PolicyContainer specifies 1180 the structure, content, and optionally, source, target, and 1181 metadata information for a SUPAPolicy. This is implemented by the 1182 subclasses of SUPAPolicyStructure. For example, the composite 1183 pattern is used to create two subclasses of the SUPAECAPolicyRule 1184 class; SUPAECAPolicyRuleAtomic is used for stand-alone policies, 1185 and SUPAECAPolicyRuleComposite is used to build hierarchies of 1186 policies. 1188 This document defines a SUPAPolicy as an ECA Policy Rule, though 1189 the GPIM enables other types of policies to be defined and used 1190 with an ECA policy rule. The GPIM model is used in [2] and [5], 1191 along with extensions that allow [2] and [5] to define multiple 1192 types of policies that are derived from the GPIM. They also allow 1193 different combinations of different types of policy rules to be 1194 used with each other. Most previous work cannot define different 1195 types of policy rules; please see Appendix A for a comparison to 1196 previous work. 1198 4.3.3. SUPAPolicyComponentStructure 1200 SUPAPolicyComponentStructure is an abstract superclass that is the 1201 base class for defining components of different types of policies. 1202 SUPAPolicyStructure subclasses define the structure of a policy, 1203 while SUPAPolicyComponentStructure subclasses define the content 1204 that is contained in the structure of a policy. For example, a 1205 SUPAECAPolicyRule is an imperative policy rule, and defines its 1206 structure; its event, condition, and action clauses are populated 1207 by SUPAPolicyComponentStructure subclasses. The strength of this 1208 design is that different types of policies (e.g., imperative and 1209 declarative policies) can be represented using a common set of 1210 policy components. 1212 Please see Appendix for a comparison to previous work. 1214 4.3.4. SUPAPolicyClause 1216 All policies derived from the GPIM are made up of one or more 1217 SUPAPolicyClauses, which define the content of the Policy. 1218 This enables a Policy of one type (e.g., ECA) to invoke Policies 1219 of the same or different types. SUPAPolicyClause is an abstract 1220 class, and serves as a convenient aggregation point for assembling 1221 other objects that make up a SUPAPolicyClause. 1223 The GPIM defines a single concrete subclass of SUPAPolicyClause, 1224 called SUPAEncodedClause. This is a generic clause, and can be 1225 used by any type of Policy in a stand-alone fashion. It can also 1226 be used in conjunction with other SUPAPolicyClauses. The EPRIM 1227 also defines a subclass of SUPAPolicyClause; see section 6.7). 1229 The structure of the GPIM is meant to provide an extensible 1230 framework for defining different types of policies. This is 1231 demonstrated by the EPRIM (see section 6) and the LSIM (see the 1232 Appendices) that each define new subclasses of SUPAPolicyClause 1233 (i.e., SUPABooleanClause and SUPALogicClause, respectively) 1234 without defining new classes that have no GPIM superclass. 1236 A SUPAPolicyClause is defined as an object. Therefore, clauses and 1237 sets of clauses are objects, which promotes reusability. 1239 4.3.5. SUPAPolicyComponentDecorator 1241 One of the problems in building a policy model is the tendency to 1242 have a multitude of classes, and hence object instances, to 1243 represent different combinations of policy events, conditions, and 1244 actions. This can lead to class and/or relationship explosion. 1245 Please see Appendix A for a comparison to previous work. 1247 SUPAPolicyClauses are constructed using the Decorator Pattern 1248 [11]. This is a design pattern that enables behavior to be 1249 selectively added to an individual object, either statically or 1250 dynamically, without affecting the behavior of other objects from 1251 the same class. The decorator pattern uses composition, instead of 1252 inheritance, to avoid class and relationship explosion. The 1253 decorator pattern also enable new objects to be composed from 1254 parts or all of existing objects without affecting the existing 1255 objects. 1257 This enables the resulting SUPAPolicyClause to be constructed 1258 completely from objects in the SUPA information model. This 1259 facilitates the construction of policies at runtime by a machine. 1260 This is also true of [2] and [5]; however, this is NOT true of 1261 most other models. Please see Appendix A for a comparison to 1262 previous work. 1264 SUPAPolicyComponentDecorator defines four types of objects that 1265 can be used to form a SUPAPolicyClause. Each object may be used 1266 with all other objects, if desired. The first three are defined 1267 in the GPIM, with the last defined in the EPRIM. The objects are: 1269 o SUPAPolicyTerm, which enables a clause to be defined in a 1270 canonical {variable, operator, value} form 1271 o SUPAVendorDecoratedComponent, which enabled a custom object 1272 to be defined and then used in a SUPAPolicyClause 1273 o SUPAPolicyCollection, which enables a collection of objects 1274 to be gathered together and associated with all or a portion 1275 of a SUPAPolicyClause 1276 o SUPAECAComponent, which defines Events, Conditions, and 1277 Actions as reusable objects 1279 This approach facilitates the machine-driven construction of 1280 policies. Note that this is completely optional; policies do not 1281 have to use these constructs. 1283 4.3.6. SUPAPolicyTarget 1285 A SUPAPolicyTarget is a set of managed entities that a SUPAPolicy 1286 is applied to. A managed entity can only be designated a 1287 SUPAPolicyTarget if it can process actions from a SUPAPolicy. 1289 A managed object may not be in a state that enables management 1290 operations to be performed on it. Furthermore, the policy-based 1291 management system SHOULD ensure that the management entity 1292 performing the management operations has the proper permissions to 1293 perform the management operations. The design of the 1294 SUPAPolicyTarget addresses both of these criteria. 1296 4.3.7. SUPAPolicySource 1298 A SUPAPolicySource is a set of managed entities that authored, or 1299 are otherwise responsible for, this SUPAPolicy. Note that a 1300 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 1301 primary use is for auditability and the implementation of deontic 1302 and/or alethic logic. 1304 4.4. The Design of the GPIM 1306 This section describes the overall design of the GPIM. 1308 The GPIM defines a policy as a type of PolicyContainer. For this 1309 version, only ECA Policy Rules will be described. However, it 1310 should be noted that the mechanism described is applicable to 1311 other types of policies (e.g., declarative) as well. 1313 4.4.1. Structure of Policies 1315 Recall that a PolicyContainer was defined as a special type of 1316 container that provides at least the following three functions: 1318 1. It uses metadata to define how its content is described 1319 and/or prescribed 1320 2. It separates the content of the policy from the 1321 representation of the policy 1322 3. It provides a convenient control point for OAMP operations. 1324 The first requirement is provided by the ability for any subclass 1325 of Policy (the root of the information model) to aggregate one or 1326 more concrete instances of a SUPAPolicyMetadata class. This is 1327 explained in detail in section 5.2.2. 1329 The second requirement is met by representing an ECA Policy as 1330 having two parts: (1) a rule part and (2) components that make up 1331 the rule. Since functional and declarative policies are not, 1332 strictly speaking, "rules", the former is named PolicyStructure, 1333 while the latter is named PolicyComponentStructure. 1335 The third requirement is met by the concrete subclasses of 1336 PolicyStructure. Since they are PolicyContainers, they are made 1337 up of the SUPAECAPolicyRule, its commponents, and any metadata 1338 that applies to the PolicyContainer, the SUPAECAPolicyRule, and.or 1339 any components of the SUPAECAPolicyRule. This provides optional 1340 low-level control over any part of the SUPAECAPolicyRule. 1342 The above requirements result in the design shown in Figure 4. 1344 A SUPAHasPolicyMetadata A 1345 +------------------+/ \ \+--------------------+ 1346 | SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata | 1347 +---------+--------+\ / /+--------------------+ 1348 / \ 0..n 0..n 1349 I 1350 I 1351 +------+------------------------------------+ 1352 I I 1353 A I A I 1354 +--------+------------+ +------------------+-----------+ 1355 | SUPAPolicyStructure | | SUPAPolicyComponentStructure | 1356 +--------+------------+ +-------------+----------------+ 1357 / \ / \ 1358 I I 1359 I I 1360 (subclasses representing (subclasses representing 1361 different types of policies) different policy components) 1363 Figure 4. Structure of a Policy 1365 Note that aggregation in Figure 4 (named SUPAHasPolicyMetadata) 1366 is realized as an association class, in order to manage which set 1367 of Metadata can be aggregated by which SUPAPolicyObject. The 1368 combination of these three functions enables a PolicyContainer 1369 to define the behavior of how its constituent components will be 1370 accessed, queried, stored, retrieved, and how they operate. 1372 It is often necessary to construct groups of policies. The GPIM 1373 follows [2] and [5], and uses the composite pattern [11] to 1374 implement this functionality, as shown in Figure 5 below. There 1375 are a number of advantages to using the composite pattern over a 1376 simple relationship, as detailed in [11]. 1378 Figure 5 shows that SUPAPolicyStructure has a single subclass, 1379 called SUPAECAPolicyRule. Note, however, that other types of 1380 policies, such as declarative policies, can be defined as 1381 subclasses of SUPAPolicyStructure in the future. 1383 A 1384 +---------------------+ 1385 | SUPAPolicyStructure | 1386 +--------+------------+ 1387 / \ 1388 I 1389 I 1390 +---------------+----------------+ 1391 I I 1392 C I A I 1393 +----------------+---------------+ +-----------+-----------+ 1394 | Future Subclasses to Represent | | SUPAECAPolicyRule | 1395 | Represent Different Policies | +-----------------------+ 1396 +--------------------------------+ 1398 Figure 5. The Composite Pattern Applied to SUPAPolicyStructure 1400 4.4.2. Representing an ECA Policy Rule 1402 An ECA policy rule is a 3-tuple, made up of one or more event 1403 clauses, one or more condition clauses, and one or more action 1404 clauses. Each clause may be viewed as a predicate, as it provides 1405 a TRUE or FALSE output. The canonical form of a clause is a 1406 3-tuple of the form "variable operator value", and can be made 1407 into more complex Boolean expressions. For example, the 1408 SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two 1409 clauses, "(A AND B)" and "(C OR D)", that are combined together 1410 using the operators OR and NOT. 1412 A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract 1413 subclass of SUPAPolicyStructure. 1415 A A 1416 +---------------------------+ +------------------+ 1417 | SUPAPolicyStructure | | SUPAPolicyClause | 1418 +---------+---------+-------+ +--------+----+----+ 1419 / \ / \ 0..1 1..n / \ / \ 1420 I A | I 1421 I \ / | I 1422 I | | I 1423 I | SUPAHasPolicyClause | I 1424 I +------------------------+ I 1425 A I A I 1426 +------+------------+ +----------+-------+ 1427 | SUPAECAPolicyRule | | SUPAPolicyClause | 1428 +-------------------+ +------------------+ 1430 Figure 6. SUPAECAPolicyRule Aggregating SUPAPolicyClauses 1432 Note that the aggregation SUPAHasPolicyClause in Figure 6 is 1433 realized as an association class, in order to manage which set 1434 of SUPAPolicyClauses can be aggregated by which set of 1435 SUPAECAPolicyRules. This aggregation is defined at the 1436 SUPAPolicyStructure level, and not at the lower level of 1437 SUPAECAPolicyRule, so that non-ECA policies can also use this 1438 aggregation. 1440 Since a SUPAECAPolicyRule consists of three SUPAPolicyClauses, 1441 at least three separate instances of the SUPAHasPolicyClause 1442 aggregation are instantiated in order to make a complete 1443 SUPAECAPolicyRule, as shown in Figure 7. 1445 A A 1446 +-------------------+ +--------------------+ 1447 | SUPAECAPolicyRule | | SUPAPolicyClause | 1448 +--+----+----+------+ +-------+----+----+--+ 1449 / \ / \ / \ 1..n 0..n / \ / \ / \ 1450 A A A | | | 1451 \ / \ / \ / | | | 1452 | | | | | | 1453 | | | SUPAHasPolicyClause #1 | | | 1454 | | +------------------------------+ | | 1455 | | | | 1456 | | SUPAHasPolicyClause #2 | | 1457 | +----------------------------------------+ | 1458 | | 1459 | SUPAHasPolicyClause #3 | 1460 +--------------------------------------------------+ 1462 Figure 7. Instantiating a SUPAECAPolicyRule, part 1 1464 In figure 7, SUPAECAPolicyRule is shown as "owning" these three 1465 aggregations, since it inherits them from its superclass 1466 (SUPAPolicyStructure). The three aggregations represent the 1467 event, condition, and action clauses of a SUPAECAPolicyRule. 1468 Note that each of these clauses MAY consist of one or more 1469 SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist 1470 of one or more predicates. In this way, complex event, condition, 1471 and action clauses, which are combinations of Boolean expressions 1472 that form a logical predicate) are supported, without having to 1473 define additonal objects (as is done in previous work; please 1474 see Appendix A for a comparison to previous work. 1476 The multiplicity of the SUPAHasPolicyClause aggregation is 1477 0..n on the aggregate side and 1..n on the part side. This means 1478 that a particular SUPAECAPolicyRule MUST aggregate at least one 1479 SUPAPolicyClause, and that a given SUPAPolicyClause MAY be 1480 aggregated by zero or more SUPAECAPolicyRule objects. 1482 This cardinality MAY be refined to 3..n for SUPAECAPolicyRules, 1483 since a SUPAECAPolicyRule MUST have at least three separate clauses. 1484 However, since a SUPAPolicyStructure is the owner of this 1485 aggregation (which is inherited by SUPAECAPolicyRule), the 1486 cardinality is defined to be 1..n on the part side because other 1487 types of Policies have different needs. The 0..n cardinality 1488 means that a SUPAPolicyClause may be aggregated by zero or more 1489 SUPAECAPolicyRules. The zero is provided so that SUPAPolicyClauses 1490 can be stored in (for example) a repository before the 1491 SUPAECAPolicyRule is created; the "or more" recognizes the fact 1492 that multiple SUPAECAPolicyRules could aggregate the same 1493 SUPAPolicyClause. 1495 In Figure 7, suppose that SUPAHasPolicyClause#1, #2, and #3 1496 represent the aggregations for the event, condition, and action 1497 clauses, respectively. This means that each of these 1498 SUPAHasPolicyClause aggregations must explicitly identify the 1499 type of clause that it represents. 1501 In looking at Figure 7, there is no difference between any of the 1502 three aggregations, except for the type of clause that the 1503 aggregation represents (i.e., event, condition, or action clause). 1505 Therefore, three different aggregations, each with their own 1506 association class, is not needed. Instead, the GPIM defines a 1507 single aggregation (SUPAHasPolicyClause) that is realized using a 1508 (single) abstract association class (SUPAHasPolicyClauseDetail); 1509 this association class is then subclassed into three concrete 1510 subclasses, one each to represent the semantics for an event, 1511 condition, and action clause. 1513 The policy management system may use any number of different 1514 software mechanisms, such as introspection or reflection, to 1515 determine the nature of the aggregation (i.e., what object types 1516 are being aggregated) in order to select the appropriate subclass 1517 of SUPAHasPolicyClauseDetail. The three subclasses of 1518 SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail, 1519 SUPAHasPolicyConditionDetail, and SUPAHasPolicyActionDetail, 1520 respectively. While Event, Condition, and Action objects are 1521 typically used in ECA policy rules, the design in this document 1522 enables them to be used as policy components of other types of 1523 policies as well. This is shown in Figure 8. 1525 A A 1526 +-------------------+ +------------------+ 1527 | SUPAECAPolicyRule | | SUPAPolicyClause | 1528 +---------+---------+ +----------+-------+ 1529 / \ 1..n 0..n / \ 1530 A | 1531 \ / | 1532 | | 1533 | SUPAHasPolicyClause | 1534 +--------------+-----------------+ 1535 ^ 1536 | 1537 A | 1538 +--------------+------------+ 1539 | SUPAHasPolicyClauseDetail | 1540 +--------------+------------+ 1541 / \ 1542 I 1543 I 1544 +----------------+-----------------------+ 1545 I I I 1546 C I C I C I 1547 +--------+-----+ +-------+----------+ +---------+-----+ 1548 |Event subclass| |Condition subclass| |Action subclass| 1549 +--------------+ +------------------+ +---------------+ 1551 Figure 8. Instantiating a SUPAECAPolicyRule, part 2 1553 4.4.3. Creating SUPA Policy Clauses 1555 There are two different types of Policy Components. They are a 1556 SUPAPolicyClause and a SUPAPolicyComponentDecorator. The former 1557 is used to construct SUPAECAPolicyRules, while the latter is used 1558 to add behavior to a SUPAPolicyClause. This enables the structure 1559 and capabilities of the SUPAPolicyClause to be adjusted 1560 dynamically at runtime. 1562 However, since each SUPAECAPolicyRule can be made up of a variable 1563 number of SUPAPolicyComponents, the decorator pattern is used to 1564 "wrap" any concrete subclass of SUPAPolicyClause with zero or more 1565 concrete subclasses of the PolicyComponentDecorator object. This 1566 avoids problems of earlier models that resulted in a proliferation 1567 of classes and relationships. 1569 Figure 9 shows these two class subclasses. Note that the decorator 1570 pattern [11] is used to enable subclasses of the 1571 SUPAPolicyComponentDecorator class to add their attributes and/or 1572 behavior to a SUPAPolicyClause (as stated in section 4.3) without 1573 affecting the behavior of other objects from the same class. More 1574 specifically, concrete subclasses of the (abstract) 1575 SUPAPolicyComponentDecorator class can be used to decorate, or 1576 "wrap", any of the concrete subclasses of the (abstract) 1577 SUPAPolicyClause class. 1579 A 1580 +------------------------------+ 1..n 1581 | SUPAPolicyComponentStructure +----------------------+ 1582 +----------------+-------------+ | 1583 / \ | 1584 I SUPAHasPolicyComponentDecorators | 1585 I | 1586 +--------------+-----------+ | 1587 I I | 1588 A I A I | 1589 +---------+--------+ +--------------+---------------+ 0..1 | 1590 | | | |/ \ | 1591 | SUPAPolicyClause | | SUPAPolicyComponentDecorator + A -----+ 1592 | | | |\ / 1593 +------------------+ +------------------------------+ 1595 Figure 9. Subclasses of SUPAPolicyComponentStructure 1597 Instead of using inheritance to statically create new classes to 1598 represent new types of objects, the decorator pattern uses 1599 composition to dynamically combine attributes and behavior from 1600 existing objects into new objects. This is done by defining an 1601 interface in SUPAPolicyComponent that all of the subclasses of 1602 SUPAPolicyComponent conform to. Since the subclasses are of the 1603 same type as SUPAPolicyComponent, they all have the same interface. 1604 This allows each concrete SUPAPolicyComponentDecorator subclass to 1605 add its attributes and/or behavior to the concrete subclass of 1606 SUPAPolicyClause that it is decorating (or "wrapping"). 1608 This represents an important design optimization for data models. 1609 Note that a single SUPAECAPolicyRule can consist of any number of 1610 SUPAPolicyClauses, each of very different types. If inheritance 1611 was used, then a subclass AND an aggregation would be required for 1612 each separate clause that makes up the policy rule. 1614 Clearly, continuing to create subclasses is not practical. Worse, 1615 suppose composite objects are desired (e.g., a new object Foo is 1616 made up of existing objects Bar and Baz). If all that was needed 1617 was one attribute of Bar and two of Baz, the developer would still 1618 have to use the entire Bar and Baz classes. This is wasteful and 1619 inefficient. In contrast, the decorator pattern enables all, or 1620 just some, of the attributes and/or behavior of a class to "wrap" 1621 another class. This is used heavily in many production systems 1622 (e.g., the java.io package) because the result is only the 1623 behavior that is required, and no other objects are affected. 1625 The SUPAPolicyComponentDecorator class hierarchy is used to define 1626 objects that may be used to construct a SUPAPolicyClause. The 1627 decorator object can add behavior before, and/or after, it 1628 delegates to the object that it is decorating. The subclasses of 1629 SUPAPolicyComponentDecorator provide a very flexible and completely 1630 dynamic mechanism to: 1632 1) add or remove behavior to/from an object 1633 2) ensure that objects are constructed using the minimum amount 1634 of features and functionality required 1636 SUPAPolicyComponentDecorator defines four subclasses, as shown in 1637 Figure 10. 1639 A 1640 +------------------------------+ 1641 | SUPAPolicyComponentDecorator | 1642 +--------------+---------------+ 1643 / \ 1644 I 1645 I 1646 I 1647 +------------+-------------+----------------+ 1648 I I I I 1649 A I I C I I 1650 +--------+-------+ I +---------+------------+ I 1651 | SUPAPolicyTerm | I | SUPAPolicyCollection | I 1652 +----------------+ I +----------------------+ I 1653 (for defining I (for defining sets and/or I 1654 clauses in I groups of objects) I 1655 canonical form) I I 1656 I I 1657 C I A I 1658 +---------------+--------------+ +---------+--------+ 1659 | SUPAVendorDecoratedComponent | | SUPAECAComponent | 1660 +------------------------------+ +------------------+ 1661 (for decorating concrete (for defiing reusable 1662 subclasses of SUPAPolicyClause) event, condition, 1663 and action objects) 1665 Figure 10. Subclasses of SUPAPolicyComponentDecorator 1667 If a SUPAEncodedClause is being used, then there is no need to 1668 use any of the SUPAPolicyComponentDecorator subclasses, since 1669 the SUPAEncodedClause already completely defines the content of 1670 the SUPAPolicyClause. 1672 However, if a SUPAEncodedClause is NOT being used, then a 1673 SUPAPolicyClause will be constructed using one or more types of 1674 objects that are each subclasses of SUPAPolicyComponentDecorator. 1676 These four subclasses provide four different ways to construct a 1677 SUPAPolicyClause: 1679 1) SUPAPolicyTerm: as a {variable, operator, value} clause 1680 2) SUPAEncodedClause: as an encoded object (e.g., to pass YANG 1681 or CLI code) 1682 3) SUPAPolicyCollection: as a collection of objects that 1683 requires further processing in order to be made into a 1684 SUPAPolicyClause 1685 4) SUPAECAComponent: subclasses define reusable Event, 1686 Condition, or Action objects 1688 These four different types of objects can be intermixed. For 1689 example, the first and last types can be combined as follows: 1691 Variable == Event.baz (A) 1692 Condition BETWEEN VALUE1 and VALUE2 (B) 1693 (Event.severity == 'Critical' AND 1694 (SLA.violation == TRUE OR User.class == 'Gold')) (C) 1696 In the above rules, (A) uses Event.baz to refer to an attribute 1697 of the Event class; (B) defines two different instances of a Value 1698 class, denoted as Value1 and Value2; (C) uses the nomenclature 1699 foo.bar, where foo is the name of a class, and bar is the name of 1700 an attribute of that class. 1702 4.4.4. Creating SUPAPolicyClauses 1704 The GPIM defines a single subclass of SUPAPolicyClause, called 1705 SUPAEncodedClause. This clause is generic in nature, and MAY be 1706 used with any type of policy (ECA or otherwise). The EPRIM 1707 defines an ECA-specific subclass of the GPIM, called a 1708 SUPABooleanClause, which is intended to be used with just 1709 ECA policy rules; however, other uses are also possible. 1711 Together, the GPIM and EPRIM provide several alternatives to 1712 implement a SUPAPolicyClause, enabling the developer to 1713 optimize the solution for different constraints: 1715 1) The SUPAPolicyClause can be encoded using one or more 1716 SUPAEncodedClauses; a SUPAEncodedClause encodes the 1717 entire content of its respective event, condition, or 1718 action clause. 1719 2) The SUPAPolicyClause can be defined using one or more 1720 SUPABooleanClauses; each of the three clauses can be 1721 defined as either a single SUPABooleanClause, or a 1722 combination of SUPABooleanClauses that are logically 1723 ANDed, ORed, and/or NOTed. 1724 3) The above two mechanisms can be combined (e.g., the first 1725 used to define the event clause, and the second used to 1726 define the condition and action clauses). 1728 Figure 11 shows the subclasses of SUPAPolicyClause. 1730 A 1731 +------------------+ 1732 | SUPAPolicyClause | 1733 +--------+---------+ 1734 / \ 1735 I 1736 I 1737 I 1738 +---------------+-------------+ 1739 I I 1740 A I C I 1741 +--------+----------+ +----------+--------+ 1742 | SUPABooleanClause | | SUPAEncodedClause | 1743 +-------------------+ +-------------------+ 1745 Figure 11. Subclasses of SUPAPolicyClause 1747 SUPABooleanClause is defined in the EPRIM, and is used to 1748 construct Boolean clauses that collectively make up a 1749 SUPAPolicyClause. It is abstract, so that the composite pattern 1750 can be applied to it, which enables hierarchies of Boolean 1751 clauses to be created. SUPAEncodedClause (see section 6.7) is 1752 used to encode the content of a SUPAPolicyClause as an attribute 1753 (instead of reusable objects). 1755 4.4.5. SUPAPolicySources 1757 A SUPAPolicySource is a set of managed entities that authored, 1758 or are otherwise responsible for, this SUPAPolicy. Note that a 1759 SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its 1760 primary use is for auditability, authorization policies, and 1761 other applications of deontic and/or alethic logic. 1763 SUPAPolicyStructure defines four relationships. Two of these 1764 (SUPAHasPolicySource and SUPAHasPolicyTarget), which are both 1765 aggregations, relate a SUPAPolicyStructure to a SUPAPolicySource 1766 and a SUPAPolicyTarget, respectively. Since SUPAECAPolicyRule is 1767 a subclass of SUPAPolicyStructure, it (and its subclasses) inherit 1768 both of these aggregations. This enables SUPAPolicySources and/or 1769 SUPAPolicyTargets to be attached to SUPAECAPolicyRules (but NOT to 1770 components of a SUPAPolicy). 1772 Figure 12 shows how SUPAPolicySources and SUPAPolicyTargets are 1773 attached to a SUPAPolicy. Note that both of these aggregations 1774 are defined as optional, since their multiplicity is 0..n - 0..n. 1775 In addition, both of these aggregations are realized as 1776 association classes, in order to be able to control which 1777 SUPAPolicySources and SUPAPolicyTargets are attached to a given 1778 SUPAECAPolicyRule. 1780 A 1781 +------------------+ 1782 | SUPAPolicyObject | 1783 +--------+---------+ 1784 / \ 1785 I 1786 I 1787 I 1788 +--------------+-----+---------------------+ 1789 I I I 1790 A I C I C I 1791 +-----------+---------+ +-------+--------+ +--------+-------+ 1792 | SUPAPolicyStructure | |SUPAPolicySource| |SUPAPolicyTarget| 1793 +------+-------+------+ +----------+-----+ +----------+-----+ 1794 0..n / \ / \ 0..n 0..n / \ 0..n / \ 1795 A A | | 1796 \ / \ / | | 1797 | | | | 1798 | | | | 1799 | +--------------------+ | 1800 | SUPAHasPolicySource | 1801 | | 1802 +-------------------------------------------------+ 1803 SUPAHasPolicyTarget 1805 Figure 12. ECAPolicyRules, SUPAPolicySources, and PolicyTargets 1807 A SUPAPolicySource MAY be mapped to a role (e.g., using the 1808 role-object pattern [11]); this indirection makes the system less 1809 fragile, as entities can be transparently added or removed from 1810 the role definition without adversely affecting the definition of 1811 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 1812 SUPAPolicyMetadata. 1814 4.4.6. SUPAPolicyTargets 1816 A SUPAPolicyTarget defines the set of managed entities that a 1817 SUPAPolicy is applied to. This is useful for debugging, as well as 1818 when the nature of the application requires the set of managed 1819 entities affected by a Policy to be explicitly identified. This is 1820 determined by two conditions: 1822 1) The set of managed entities that are to be affected by the 1823 SUPAPolicy must all agree to play the role of a 1824 SUPAPolicyTarget. For example, a managed entity may not be 1825 in a state that enables SUPAPolicies to be applied to it; 1826 hence, in this case, it MUST NOT assume the role of ability 1827 SUPAPolicyTarget 1828 2) A SUPAPolicyTarget must be able to: 1829 a) process (either directly or with the aid of a proxy) 1830 SUPAPolicies, or 1831 b) receive the results of a processed SUPAPolicy and 1832 apply those results to itself. 1834 Figure 12 showed how SUPAPolicyTargets are attached to 1835 SUPAECAPolicyRules. 1837 A SUPAPolicyTarget MAY be mapped to a role (e.g., using the 1838 role-object pattern [11]); this indirection makes the system less 1839 fragile, as entities can be transparently added or removed from 1840 the role definition without adversely affecting the definition of 1841 the SUPAPolicy. Note that SUPAPolicyRole is a subclass of 1842 SUPAPolicyMetadata. 1844 4.4.7. Policy Metadata 1846 Metadata is, literally, data about data. As such, it can be 1847 descriptive or prescriptive in nature. 1849 4.4.7.1. Motivation 1851 There is a tendency in class design to make certain attributes, 1852 such as description, status, validFor, and so forth, bound to a 1853 specific class (e.g., [6]). This is bad practice in an information 1854 model. For example, different classes in different parts of the 1855 class hierarchy could require the use of any of these attributes; 1856 if one class is not a subclass of the other, then they must each 1857 define the same attribute as part of their class structure. This 1858 makes it difficult to find all instances of the attribute and 1859 ensure that they are synchronized. Furthermore, context can 1860 dynamically change the status of an object, so an easy way to 1861 update the status of one object instance without affecting other 1862 instances of the same object is required. 1864 Many models, such as [4] and [6], take a simplistic approach of 1865 defining a common attribute high in the hierarchy, and making it 1866 optional. This violates classification theory, and defeats the 1867 purpose of an information model, which is to specify the 1868 differences in characteristics and behavior between classes (as 1869 well as define how different classes are related to each other). 1870 Note that this also violates a number of well-known software 1871 architecture principles, including: 1873 o the Liskov Substitution Principle [13] 1874 (if A is a subclass of B, then objects instantiated from 1875 class B may be replaced with objects instantiated from 1876 class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS) 1877 o the Single Responsibility Principle [14] 1878 (every class should have responsibility over one, and only 1879 one, part of the functionality provided by the program) 1881 Most models use inheritance, not composition. The former is 1882 simpler, but has some well-known problems. One is called "weak 1883 encapsulaton", meaning that a subclass can use attributes and 1884 methods of a superclass, but if the superclass changes, the 1885 subclass may break. Another is that each time a new object is 1886 required, a new subclass must be created. These problems are 1887 present in [RFC3460], [4], and [6]. 1889 Composition is an alternative that provides code that is easier to 1890 use. This means that composition can provide data models that are 1891 more resistant to change and easier to use. By using composition, 1892 we can select just the metadata objects that are needed, instead 1893 of having to rely on statically defined objects. We can even 1894 create new objects from a set of existing objects through 1895 composition. Finally, we can use the decorator pattern to select 1896 just the attributes and behaviors that are required for a given 1897 instance. 1899 In [2] and [5], a separate metadata class hierarchy is defined to 1900 address this problem. This document follows this approach. 1902 4.4.7.2. Design Approach 1904 The goal of the GPIM is to enable metadata to be attached to any 1905 subclass of SUPAPolicyObject that requires it. Since this is a 1906 system intended for policy-based management, it therefore makes 1907 sense to be able to control which metadata is attached to which 1908 policies dynamically (i.e., at runtime). 1910 One solution is to use the Policy Pattern [1], [2], [6], [12]. 1911 This pattern was built to work with management systems whose 1912 actions were dependent upon context. The Policy Pattern works as 1913 follows: 1915 o Context is derived from all applicable system inputs (e.g., 1916 OAMP data from network elements, business goals, time of 1917 day, geo-location, etc.). 1918 o Context is then used to select a working set of Policies. 1919 o Policies are then used to define behavior at various 1920 control points in the system. 1921 o One simple type of control point is an association class. 1922 Since the association class represents the semantics of how 1923 two classes are related to each other, then 1924 o ECAPolicyRule actions can be used to change the attribute 1925 values, methods, and relationships of the association 1926 class 1927 o This has the affect of changing how the two classes are 1928 related to each other 1929 o Finally, as context changes, the working set of policies 1930 change, enabling the behavior to be adjusted to follow 1931 changes in context (according to appropriate business goals 1932 and other factors, of course) in a closed loop manner. 1934 Conceptually, this is accomplished as shown in Figure 13 below. 1936 Defines 1937 +----------+ Behavior +------------+ 1938 | Policies +----------------+ | SUPAPolicy | 1939 +----+-----+ 1..n | +------+-----+ 1940 0..n / \ | / \ 0..n 1941 | | A 1942 | | \ / 1943 | 1..n \ / | 1944 | +-----------+--------------+ | 1945 | | SUPAPolicyMetadataDetail | | 1946 | +-----------+--------------+ | 1947 | | | 1948 | Selects | | 1949 | Policies | | 1950 | | | 1951 | +-------------------->+ 1952 | Applies | 1953 / \ Behavior | 1954 A | 1955 0..n \ / \ / 0..n 1956 +----+-----+ +--------+---------+ 1957 | Context | |SUPAPolicyMetadata| 1958 +----------+ +------------------+ 1960 Figure 13. Context-Aware Policy Rules 1962 4.4.7.2.1. Policies and Actors 1964 The Policy Continuum ([1] [5] [10] [12]) was defined to associate 1965 different actors with different policies at different levels of 1966 business and/or technical specificity. Context-aware policy rules, 1967 and the Policy Pattern, were defined to realize this association. 1969 Four important functions related to the lifecycle of policies are 1970 design, implementation, deployment, and execution. There are many 1971 different possible definitions of these functions (even for policy 1972 lifecycle management); however, for the purposes of this document, 1973 they are defined as follows: 1975 o Design: The process of defining a software architecture 1976 to satisfy user requirements. 1977 o Development: the process of documenting, programming, 1978 testing, and maintaining code and applications 1979 as part of a software product 1980 o Deployment: the process that assembles and transfers 1981 completed software artifacts to a state that 1982 enables their execution 1983 o Execution: the process of installing, activating, running, 1984 and subsequently deactivating executable 1985 software products 1987 The design process is responsible for producing a software 1988 architecture. This emphasizes the design, as opposed to the 1989 programming, of software systems. In contrast to design, 1990 development emphasizes constructing software artifacts via coding 1991 and documentation. 1993 Deployment may be described as the process of releasing software. 1994 It includes all of the operations required to assemble a completed 1995 software product. It typically also includes the process of 1996 preparing a software product for execution (e.g., assembling a set 1997 of software products into a larger product, determining if the 1998 consumer site has appropriate resources to install and execute the 1999 software product, and collecting information on the feasbility of 2000 using the software product). This contrasts with the execution 2001 process, which is the set of processes that follow deployment. 2003 In summary, exemplar states in the policy lifecycle process 2004 include: 2006 o Design: determining how the policy-based management 2007 system will operate 2008 o Development: documenting, programming, testing, and 2009 maintaining policies and policy components 2010 o Deployment: assembling the components of a policy-based 2011 management system 2012 o Execution: installing, enabling, running, disabling, 2013 and uninstalling policies and policy components 2015 4.4.7.2.2. Deployment vs. Execution of Policies 2017 One of the primary reasons for separating the deployment and 2018 execution processes is to differentiate between environments that 2019 are not ready to execute policies (i.e., deployment) and 2020 environments that are ready to execute policies (i.e., execution). 2021 This is an important consideration, since policies that are 2022 related to the same set of tasks may be deployed in many different 2023 places (e.g., in a policy system vs. in a network device). In 2024 addition, each managed entity in the set of SUPAPolicyTargets may 2025 or may not be in a state that allows SUPAPolicies to be applied to 2026 it (see section 4.4.6.). 2028 Hence, this design includes dedicated class attributes for 2029 getting and setting the deployment and execution status, as well 2030 as enabling and disabling, SUPAPolicies (see section 5.3.1.). 2032 4.4.7.2.3. Using SUPAMetadata for Policy Deployment and Execution 2034 One way of encoding deployment and execution status for policies 2035 and policy components is to attach Metadata objects to affected 2036 SUPAPolicyStructure and SUPAPolicyComponentStructure objects. 2037 This provides an extensible and efficient means to describe 2038 and/or prescribe deployment and/or execution status of a policy 2039 or a policy component. It is extensible, since classes and 2040 relationships can be used, as opposed to a set of attributes. It 2041 is efficient, because the decorator pattern (see section 5.7) is 2042 used (this enables attributes and/or methods of objects, or the 2043 entire object, to be used to add characteristics and/or behavior 2044 to a given object. 2046 SUPAPolicyMetadata objects (see sections 5.16 - 5.20) may be 2047 attached to the SUPAECAPolicyRule and/or any of its components 2048 to define additional semantics of the SUPAECAPolicyRule. For 2049 example, SUPAAccessMetadataDef (see section 5.19) and/or 2050 SUPAVersionMetadataDef (see section 5.20) may be attached to 2051 define the access privileges and version information, 2052 respectively, of a policy rule and/or its components. 2054 The SUPAPolicyStructure contains two attributes, 2055 supaPolDeployStatus and supaPolExecStatus (see sections 5.3.1.3. 2056 and 5.3.1.4., respectively) that SUPAPolicyMetadata objects can 2057 use to get and set the deployment and execution status of a 2058 SUPAPolicy. This allows metadata to be used to alter the 2059 deployment and/or execution state of a policy (or a set of 2060 policy components) without having to affect other parts of the 2061 policy-based management system. The supaPolDeployStatus attribute 2062 indicates that this SUPAPolicy can or cannot be deployed. If it 2063 cannot be deployed. Similarly, the supaPolExecStatus attribute 2064 is used to indicate if a particular SUPAPolicy has executed, is 2065 currently executing, or is ready to execute, and whether or not 2066 the execution of that SUPAPolicy had any failures. 2068 The reverse is also true (and hence, forms a closed-loop system 2069 controlled by metadata). For example, if the set of deployed 2070 SUPAPolicies are SUPAECAPolicyRules, then when the actions of 2071 these SUPAECAPolicyRules are executed, the overall context has 2072 changed (see section 4.4.7.2). The context manager could then 2073 change attribute values (directly or indirectly) in the 2074 SUPAPolicyMetadataDetail association class. This class represents 2075 the behavior of the SUPAHasPolicyMetadata aggregation, which is 2076 used to define which SUPAPolicyMetadata can be attached to which 2077 SUPAPolicy objet in this particular context. For example, the 2078 access privileges of a policy and/or policy component could be 2079 changed dynamically, according to changes in context. 2081 By using the decorator pattern on SUPAPolicyMetadata, any number 2082 of SUPAPolicyMetadata objects (or their attributes, etc.) can be 2083 wrapped around a concrete subclass of SUPAPolicyMetadata. This is 2084 shown in Figure 14 below. 2086 4.4.7.3. Structure of SUPAPolicyMetadata 2088 SUPAPolicyMetadata also uses the decorator pattern to provide an 2089 extensible framework for defining metadata to attach to SUPAPolicy 2090 subclasses. Its two principal subclasses are 2091 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. The 2092 former is used to define concrete subclasses of SUPAPolicyMetadata 2093 that are attached at runtime to SUPAPolicy subclasses, while the 2094 latter is used to define concrete objects that represent reusable 2095 attributes, methods, and relationships that can be added to 2096 subclasses of SUPAPolicyConcreteMetadata. 2098 For example, concepts like identification, access control, and 2099 version information are too complex to represent as a single 2100 attribute, or even a couple of attributes - they require the 2101 generic power of objects to represent their characteristics and 2102 behavior. Furthermore, defining concrete classes to represent 2103 these concepts in the policy hierarchy is fragile, because: 2105 1. not all objects that use these concepts need all of the 2106 information represented by them (e.g., two subclasses of an 2107 Identification Object may be Passport and Certificate, but 2108 these two objects are rarely used together, and even those 2109 contexts that use one of these classes may not need all of 2110 the data in that class) 2111 2. defining a class means defining its attributes, methods, and 2112 relationships at a particular place in the hierarchy; this 2113 means that defining a relationship between a class A and 2114 another class B SHOULD only be done if all of the subclasses 2115 of B can use the attributes, methods, and relationships of A 2116 (e.g., in the above example, defining a relationship between 2117 an Identification Object and a superclass of a router class 2118 is not appropriate, since routers do not use Passports) 2120 A 2121 +------------------+ 2122 | SUPAPolicyObject | 2123 +--------+---------+ 2124 / \ 0..n 2125 A 2126 \ / 2127 | A 2128 | 0..n +--------------------+ 2129 | SUPAHasPolicyMetadata \| | 2130 +-------------+-----------------+ SUPAPolicyMetadata | 2131 ^ /| | 2132 | +------+------+------+ 2133 A | / \ | 1..n 2134 +-------------+---------------+ I | 2135 1..n | | I | 2136 +----------+ SUPAHasPolicyMetadataDetail | I | 2137 | | | I | 2138 | +-----------------------------+ I | 2139 | I | 2140 | (gets/sets values of attributes and/or I | 2141 | methods of the SUPAHasPolicyMetadataDetail I | 2142 | class; this affects which SUPAPolicyMetadata I | 2143 | objects can be attached to which policies I | 2144 | and policy components) I | 2145 | I | 2146 | C I | 2147 | +----------------------------+ I | 2148 | | | I | 2149 +----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+ | 2150 | | I | 2151 +----------------------------+ I | 2152 I | 2153 A I | 2154 +-----------------------------+ I | 2155 | | I | 2156 | SUPAPolicyMetadataDecorator +IIIIIIIII+ | 2157 | | | 2158 +-------+--------------+------+ | 2159 / \ / \ 0..1 | 2160 I A | 2161 I \ / | 2162 I | | 2163 subclasses for adding | | 2164 behavior to policies +-----------------------+ 2165 and policy components PolicyObjectHasMetadata 2167 Figure 14. SUPAPolicyMetadata Subclasses and Relationships 2169 Since a class encapsulates attributes, methods, and behavior, 2170 defining the Identification Object in the above example as a type 2171 of SUPAPolicyMetadata object enables the decorator pattern to be 2172 used to attach all or part of that object to other objects that 2173 need it. 2175 Figure 15 shows a portion of the SUPAPolicyMetadata hierarchy. 2177 A 2178 +--------------------+ 2179 | | HasSUPAMetadataDecorator 2180 | SUPAPolicyMetadata +-------------------+ 2181 | | 1..n | 2182 +---------+----------+ | 2183 I | 2184 I | 2185 I | 2186 +-------------+-----------------+ | 2187 | | | 2188 C | | / \ 2189 +---------+------------------+ | A 2190 | SUPAPolicyConcreteMetadata | A | 0..1 \ / 2191 +----------------------------+ +--------+------------+-------+ 2192 | SUPAPolicyMetadataDecorator | 2193 +------------+----------------+ 2194 I 2195 +------------------------------+--------+ 2196 I I 2197 I I 2198 C I C I 2199 +---------------+-------------+ +---------------------+--------+ 2200 | SUPAPolicyAccessMetadataDef | | SUPAPolicyVersionMetadataDef | 2201 +-----------------------------+ +------------------------------+ 2203 Figure 15. SUPAPolicyMetadata Subclasses and Relationships 2205 Figure 15 shows a relevant portion of the SUPAPolicyMetadata 2206 hierarchy. SUPAPolicyConcreteMetadata is a concrete class that 2207 subclasses of the SUPAPolicyMetadataDecorator class can wrap. 2208 Two such subclasses, SUPAPolicyAccessMetadataDef and 2209 SUPAPolicyVersionMetadataDef, are shown in Figure 15. This 2210 enables access control and version information to be added 2211 statically (at design time) or dynamically (at runtime) to 2212 SUPAPolicyConcreteMetadata; this enables metadata-driven systems 2213 to adjust the behavior of the management system to changes in 2214 context, business rules, services given to end-users, and other 2215 similar factors. This is discussed more in sections 5.18 - 5.20. 2217 4.5. Advanced Features 2219 This section will be completed in the next revision of this 2220 document. 2222 4.5.1. Policy Grouping 2224 This section will be completed in the next revision of this 2225 document. 2227 4.5.2. Policy Rule Nesting 2229 This section will be completed in the next revision of this 2230 document. 2232 5. GPIM Model 2233 This section defines the classes, attributes, and relationships of 2234 the GPIM. 2236 5.1. Overview 2237 The overall class hierarchy is shown in Figure 16; section numbers 2238 are appended after each class. 2240 (Class of another model that SUPA is integrating into) 2241 | 2242 +---SUPAPolicyObject (5.2) 2243 | | 2244 | +---SUPAPolicyStructure (5.3) 2245 | | 2246 | +---SUPAPolicyComponentStructure (5.4) 2247 | | | 2248 | | +---SUPAPolicyClause (5.5) 2249 | | | | 2250 | | | +---SUPAEncodedClause (5.6) 2251 | | | 2252 | | +---SUPAPolicyComponentDecorator (5.7) 2253 | | | 2254 | | +---SUPAPolicyTerm (5.8) 2255 | | | | 2256 | | | +---SUPAPolicyVariable (5.9) 2257 | | | | 2258 | | | +---SUPAPolicyOperator (5.10) 2259 | | | | 2260 | | | +---SUPAPolicyValue (5.11) 2261 | | | 2262 | | +---SUPAVendorDecoratedComponent (5.12) 2263 | | | 2264 | | +---SUPAPolicyCollection (5.13) 2265 | | 2266 | +---SUPAPolicySource (5.14) 2267 | | 2268 | +---SUPAPolicyTarget (5.15) 2269 | 2270 +---SUPAPolicyMetadata (5.16) 2271 | 2272 +---SUPAPolicyConcreteMetadata (5.17) 2273 | 2274 +---SUPAPolicyMetadataDecorator (5.18) 2275 | 2276 +---SUPAPolicyAccessMetadataDef (5.19) 2277 | 2278 +---SUPAPolicyVersionMetadataDef (5.20) 2280 Figure 16: Main Classes of the GPIM 2282 SUPAPolicy is the root of the SUPA class hierarchy. For 2283 implementations, it is assumed that SUPAPolicy is subclassed from 2284 a class from another model. 2286 Classes, attributes, and relationships that are marked as 2287 "mandatory" MUST be part of a conformant implementation (i.e., a 2288 schema MUST contain these entities). This does not mean that these 2289 entities must be instantiated; rather it means that they must be 2290 able to be instantiated. Classes, attributes, and relationships 2291 that are marked as "optional" MAY be part of a conformant 2292 implementation. 2294 Unless otherwise stated, all classes (and attributes) defined in 2295 this section were abstracted from DEN-ng [2], and a version of 2296 them are in the process of being added to [5]. However, the work 2297 in [5] has been put on hold, and the names of many of the classes, 2298 attributes, and relationships are slightly different. 2300 5.2. The Abstract Class "SUPAPolicyObject" 2302 This is a mandatory abstract class. Figure 17 shows the 2303 SUPAPolicyObject class, and its four subclasses. 2305 A 0..n 0..n A 2306 +----------------+/ \ \+------------------+ 2307 |SUPAPolicyObject+ A ------------------------+SUPAPolicyMetadata| 2308 +--------+-------+\ / SUPAHasPolicyMetadata /+------------------+ 2309 / \ 2310 I 2311 I 2312 +-----------------+----------------+-----------+ 2313 I I I I 2314 A I I I I 2315 +--------+------------+ I I I 2316 | SUPAPolicyStructure | I I I 2317 +---------------------+ I I I 2318 A I I I 2319 +-----------------+------------+ I I 2320 | SUPAPolicyComponentStructure | I I 2321 +------------------------------+ I I 2322 C I I 2323 +---------+--------+ I 2324 | SUPAPolicyTarget | I 2325 +------------------+ I 2326 C I 2327 +----------+-------+ 2328 | SUPAPolicySource | 2329 +------------------+ 2331 Figure 17. SUPAPolicyObject and Its Subclasses 2333 This class is the root of the SUPA class hierarchy. It defines the 2334 common attributes and relationships that all SUPA subclasses 2335 inherit. 2337 A SUPAPolicyObject MAY be qualified by a set of zero or more 2338 SUPAPolicyMetadata objects. This is provided by the 2339 SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This 2340 enables the semantics of the SUPAPolicyObject to be more 2341 completely specified. 2343 5.2.1. SUPAPolicyObject Attributes 2345 This section defines the attributes of the SUPAPolicyObject class. 2346 These attributes are inherited by all subclasses of the GPIM 2347 except for the SUPAPolicyMetadata class, which is a sibling class. 2349 5.2.1.1. Object Identifiers 2351 This document defines two class attributes in SUPAPolicyObject, 2352 called supaPolObjIDContent and supaPolObjIDEncoding, that together 2353 define a unique object ID. This enables all class instances to be 2354 uniquely identified. 2356 One of the goals of SUPA is to be able to generate different data 2357 models that support different types of protocols and repositories. 2358 This means that the notion of an object ID must be generic. It is 2359 inappropriate to use data modeling concepts, such as keys, GUIDs, 2360 UUIDs, FQDNs, URIs, and other similar mechanisms, to define the 2361 structure of an information model. Therefore, a synthetic object 2362 ID is defined using these two attributes. This can be used to 2363 facilitate mapping to different data model object schemes, such 2364 as those depending on URIs, FQDNs, UUIDs, primary key-foreign key 2365 relationships, UUIDs, and others can all be accommodated. 2367 The two attributes work together, with the supaPolObjIDContent 2368 attribute defining the content of the object ID and the 2369 supaPolObjIDEncoding attribute defining how to interpret the 2370 content. These two attributes form a tuple, and together enable 2371 a machine to understand the syntax and value of an object 2372 identifier for the object instance of this class. 2374 Similarly, all SUPA classes are attributes are both uniquely 2375 named as well as prepended with the prefixes "SUPA" and "supa", 2376 respectively, to facilitate model integration. 2378 5.2.1.2. The Attribute "supaPolObjIDContent" 2380 This is a mandatory string attribute that represents part of the 2381 object identifier of an instance of this class. It defines the 2382 content of the object identifier. It works with another class 2383 attribute, called supaPolObjIDEncoding, which defines how to 2384 interpret this attribute. These two attributes form a tuple, 2385 and together enable a machine to understand the syntax and value 2386 of an object identifier for the object instance of this class. 2387 This is based on the DEN-ng class design [2]. 2389 5.2.1.3. The Attribute "supaPolObjIDEncoding" 2391 This is a mandatory non-zero enumerated integer attribute that 2392 represents part of the object identifier of an instance of this 2393 class. It defines the format of the object identifier. It works 2394 with another class attribute, called supaPolObjIDContent, which 2395 defines the content of the object ID. These two attributes form 2396 a tuple, and together enable a machine to understand the syntax 2397 and value of an object identifier for the object instance of 2398 this class. The supaPolObjIDEncoding attribute is mapped to the 2399 following values: 2401 0: undefined 2402 1: GUID 2403 2: UUID 2404 3: primary key 2405 4: foreign key 2406 5: URI 2407 6: FQDN 2409 The value 0 may be used to initialize the system, or to signal 2410 that there is a problem with this particular SUPAPolicyObject. 2412 5.2.1.4. The Attribute "supaPolicyDescription" 2414 This is an optional string attribute that defines a free-form 2415 textual description of this object. 2417 5.2.1.5. The Attribute "supaPolicyName" 2419 This is an optional string attribute that defines the name of this 2420 Policy. This enables any existing generic naming attribute to be 2421 used for generic naming, while allowing this attribute to be used 2422 to name Policy entities in a common manner. Note that this is NOT 2423 the same as the commonName attribute of the Policy class defined 2424 in [RFC3060], as that attribute is intended to be used with just 2425 X.500 cn attributes. 2427 5.2.2. SUPAPolicyObject Relationships 2429 The SUPAPolicyObject class currently defines a single relationship, 2430 as defined in the subsections below. 2432 5.2.2.1. The Aggregation "SUPAHasPolicyMetadata" 2434 This is a mandatory aggregation that defines the set of 2435 SUPAPolicyMetadata that are aggregated by this particular 2436 SUPAPolicyObject. This aggregation is defined in section 2437 5.16.2. 2439 5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail" 2441 This is a mandatory concrete association class that defines the 2442 semantics of the SUPAPolicyMetadata aggregation. This enables the 2443 attributes and relationships of the SUPAPolicyMetadataDetail class 2444 to be used to constrain which SUPAPolicyMetadata objects can be 2445 aggregated by this particular SUPAPolicyObject instance. This 2446 association class is defined in Section 5.16.3. 2448 5.3. The Abstract Class "SUPAPolicyStructure" 2450 This is a mandatory abstract class that is used to represent the 2451 structure of a SUPAPolicy. This class (and all of its subclasses) 2452 is a type of PolicyContainer. SUPAPolicyStructure was abstracted 2453 from DEN-ng [2], and a version of this class is in the process of 2454 being added to [5]. However, the version in [5] differs 2455 significantly. First, the class and relationship definitions ared 2456 different. Second, [5] uses the composite pattern. Neither of 2457 these are implemented in this document because of optimizations 2458 done to the SUPA class hierarchy that are NOT present in [5]. 2460 For this release, the only official type of policy that is 2461 supported is the event-condition-action (ECA) type of policy rule. 2462 However, the structure of the SUPA hierarchy is defined to 2463 facilitate adding new types of rules later. 2465 A SUPAPolicy may take the form of an individual policy or a set 2466 of policies. This requirement is supported by applying the 2467 composite pattern to subclasses of the SUPAPolicyStructure class, 2468 as shown in Figure 5. In this document, this is done for the 2469 SUPAECAPolicyRule subclass, and results in two subclasses: 2470 SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and 2471 SUPAECAPolicyRuleComposite (for defining hierarchies of policies). 2473 Note that there is no need for a "match strategy attribute" that 2474 some models [RFC3460], [4], [6] have; this is because the 2475 SUPAPolicyStructure class is used just for containment. Hence, the 2476 containers themselves serve as the scoping component for nested 2477 policies. 2479 5.3.1. SUPAPolicyStructure Attributes 2481 The following subsections define the attributes of the 2482 SUPAPolicyStructure class. 2484 The SUPAPolicyStructure class has a number of attributes that have 2485 no counterpart in the SUPAPolicyComponentStructure class. This is 2486 because these attributes are only appropriate at the level of a 2487 policy rule, not at the level of a policy component. 2489 Care must be taken in adding attributes to this class, 2490 because the behavior of future subclasses of this class (e.g., 2491 declarative and functional policies) is very different than the 2492 behavior of SUPAECAPolicyRules. 2494 5.3.1.1. The Attribute "supaPolAdminStatus" 2496 This is an optional attribute, which is an enumerated non-negative 2497 integer. It defines the current administrative status of this 2498 SUPAPolicyClause. 2500 This attribute can be used to place this particular 2501 SUPAPolicyStructure object instance into a specific administrative 2502 state, such as enabled, disabled, or in test. Values include: 2504 0: Unknown (an error state) 2505 1: Enabled 2506 2: Disabled 2507 3: In Test (i.e., no operational traffic can be passed) 2509 Value 0 denotes an error that prevents this SUPAPolicyStructure 2510 from being used. Values 1 and 2 mean that this SUPAPolicyStructure 2511 is administratively enabled or disabled, respectively. A value of 2512 3 means that this SUPAPolicyStructure is in a special test mode 2513 and SHOULD NOT be used as part of an OAM&P policy. 2515 5.3.1.2. The Attribute "supaPolContinuumLevel" 2517 This is an optional non-negative integer attribute. It defines 2518 the level of abstraction, or policy continuum level [10], of this 2519 particular SUPAPolicy. The value assignment of this class is 2520 dependent on the application; however, it is recommended that 2521 for consistency with other SUPA attributes, the value of 0 is 2522 reserved for initialization and/or error conditions. 2524 By convention, lower values represent more abstract levels of the 2525 policy continuum. For example, a value of 1 could represent 2526 business policy, a value of 2 could represent application-specific 2527 policies, and a value of 3 could represent low=level policies for 2528 network administrators. 2530 5.3.1.3. The Attribute "supaPolDeployStatus" 2532 This is an optional enumerated, non-negative integer attribute. The 2533 purpose of this attribute is to indicate that this SUPAPolicy can 2534 or cannot be deployed by the policy management system. This 2535 attribute enables the policy manager to know which SUPAPolicies to 2536 retrieve, and may be useful for the policy execution system for 2537 planning the staging of SUPAPolicies. Values include: 2539 0: undefined 2540 1: deployed and enabled 2541 2: deployed and in test 2542 3: deployed but not enabled 2543 4: ready to be deployed 2544 5: cannot be deployed 2546 If the value of this attribute is 0 or 5, then the policy 2547 management system SHOULD ignore this SUPAPolicy. Otherwise, the 2548 policy management MAY use this SUPAPolicy. 2550 5.3.1.4. The Attribute "supaPolExecStatus" 2552 This is an optional attribute, which is an enumerated, 2553 non-negative integer. It defines the current execution status 2554 of this SUPAPolicy. Values include: 2556 0: undefined 2557 1: executed and SUCEEDED (operational mode) 2558 2: executed and FAILED (operational mode) 2559 3: currently executing (operational mode) 2560 4: ready to execute (operational mode) 2561 5: executed and SUCEEDED (test mode) 2562 6: executed and FAILED (test mode) 2563 7: currently executing (test mode) 2564 8: ready to execute (test mode) 2566 5.3.1.5. The Attribute "supaPolExecFailStrategy" 2568 This is an optional non-negative, enumerated integer that defines 2569 what actions, if any, should be taken by this 2570 SUPAPolicyStructure object if it fails to execute correctly. 2572 Note that some systems may not be able to support all options 2573 specified in this enumeration. If rollback is supported by the 2574 system, then option 2 may be skipped. Options 3 and 4 can be used 2575 by systems that do and do not support rollback. Values include: 2577 0: undefined 2578 1: attempt rollback of all actions taken and stop execution 2579 2: attempt rollback of only the action that failed and stop 2580 execution 2581 3: stop execution but do not rollback any actions 2582 4: ignore failure and continue execution 2584 A value of 0 can be used as an error condition. A value of 1 means 2585 that ALL execution is stopped, rollback of all actions (whether 2586 successful or not) is attempted, and that SUPAPolicies that 2587 otherwise would have been executed are ignored. A value of 2 means 2588 that execution is stopped, and rollback is attempted for ONLY the 2589 SUPAPolicy that failed to execute correctly. 2591 5.3.2. SUPAPolicyStructure Relationships 2593 The SUPAPolicyStructure class owns four relationships, which are 2594 defined in the following subsections. 2596 5.3.2.1. The Aggregation "SUPAHasPolicySource" 2598 This is an optional aggregation, and defines the set of 2599 SUPAPolicySource objects that are attached to this particular 2600 SUPAPolicyStructure object. The semantics of this aggregation 2601 are defined by the SUPAHasPolicySourceDetail association class. 2602 PolicySource objects are used for authorization policies, as well 2603 as to enforce deontic and alethic logic. 2605 The multiplicity of this aggregation is 0..n - 0..n. This means 2606 that it is an optional aggregation; zero or more SUPAPolicySource 2607 objects may be aggregated by this SUPAPolicyStructure object, 2608 and zero or more SUPAPolicyStructure objects may aggregate this 2609 particular SUPAPolicySource object. 2611 5.3.2.2. The Association Class "SUPAHasPolicySourceDetail" 2613 This is an optional association class, and defines the semantics 2614 of the SUPAHasPolicySource aggregation. The attributes and 2615 relationships of this class can be used to define which 2616 SUPAPolicySource objects can be attached to which particular set 2617 of SUPAPolicyStructure objects. 2619 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" 2621 This is an optional Boolean attribute. If the value of this 2622 attribute is true, then this SUPAPolicySource object has been 2623 authenticated by this particular SUPAPolicyStructure object. 2625 5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" 2627 This is an optional Boolean attribute. If the value of this 2628 attribute is TRUE, then this particular SUPAPolicySource object 2629 has been verified to be trusted by this particular 2630 SUPAPolicyStructure object. 2632 5.3.2.3. The Aggregation "SUPAHasPolicyTarget" 2634 This is an optional aggregation, and defines the set of 2635 SUPAPolicyTargets that are attached to this particular 2636 SUPAPolicyStructure. The semantics of this aggregation is 2637 defined by the SUPAHasPolicyTargetDetail association class. The 2638 purpose of this class is to explicitly identify managed objects 2639 that will be affected by the execution of one or more SUPAPolicies. 2641 The multiplicity of this aggregation is 0..n - 0..n. This means 2642 that it is an optional aggregation; zero or more SUPAPolicyTarget 2643 objects may be aggregated by this SUPAPolicyStructure object, 2644 and zero or more SUPAPolicyStructure objects may aggregate this 2645 particular SUPAPolicyTarget object. 2647 5.3.2.4. The Association Class "SUPAHasPolicyTargetDetail" 2649 This is an optional association class, and defines the semantics 2650 of the SUPAPolicyTargetOf aggregation. The attributes and 2651 relationships of this class can be used to define which 2652 SUPAPolicyTargets can be attached to which particular set of 2653 SUPAPolicyStructure objects. 2655 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" 2657 This is an optional Boolean attribute. If the value of this 2658 attribute is true, then this SUPAPolicyTarget object has been 2659 authenticated by this particular SUPAPolicyStructure object. 2661 5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" 2663 This is an optional Boolean attribute. If its value is TRUE, then 2664 this SUPAPolicyTarget is able to be used as a SUPAPolicyTarget. 2665 This means that it meets two specific criteria: 2667 1. it has agreed to play the role of a SUPAPolicyTarget (i.e., 2668 it is willing to have SUPAPolicies applied to it, and 2669 2. it is able to either process (directly or with the aid of 2670 a proxy) SUPAPolicies or receive the results of a processed 2671 SUPAPolicy and apply those results to itself. 2673 5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" 2675 This is an optional association that defines which, if any, actions 2676 should be taken if this SUPAPolicyStructure object instance fails 2677 to execute correctly. The semantics of this association are defined 2678 in the SUPAHasPolExecFailTakeActionDetail association class. 2680 For a given SUPAPolicyStructure object A, this association defines 2681 a set of policy action objects B to execute if (and only if) the 2682 SUPAPolicyStructure object A failed to execute correctly. The 2683 multiplicity of this association is defined as 0..n on the owner 2684 (A) side and 1..n on the part (B) side. This means that this 2685 association is optional; if it is instantiated, then at least one 2686 SUPAPolicyStructure MUST be instantiated by this 2687 SUPAPolicyStructure object. Similarly, one or more 2688 SUPAPolicyStructure objects may be associated with this given 2689 SUPAPolicyStructure object. 2691 5.3.2.6. The Association Class "SUPAHasPolExecFailTakeActionDetail" 2693 This is an optional concrete class that defines the semantics for 2694 the SUPAHasPolExecFailTakeAction association. The attributes and/or 2695 relationships of this association class can be used to determine 2696 which policy action objects are executed in response to a failure 2697 of the SUPAPolicyStructure object instance that owns this 2698 association. The association relates the policy actions from one 2699 SUPAPolicyStructure B to be executed if a SUPAPolicyStructure A 2700 fails to execute properly. Figure 18 illustrates this approach. 2702 A 2703 +---------------------------+ 0..n 2704 | +---------------------------------+ 2705 | | SUPAHasPolExecFailTakeAction | 2706 | SUPAPolicyStructure |/ | 2707 | + --------------+-----------------+ 2708 | |\ ^ 2709 +---------------------------+ 1..n | 2710 | 2711 C | 2712 +------------------+-----------------+ 2713 | SUPAHasPolExecFailTakeActionDetail | 2714 +------------------------------------+ 2716 Figure 18. SUPAHasPolExecFailTakeAction Association 2718 5.3.2.6.1. The Attribute "supaPolExecFailTakeActionEncoding" 2720 This is an optional enumerated, non-negative integer attribute 2721 that defines how to find the set of SUPAPolicyActions contained 2722 in each element of the supaPolExecFailTakeActionName class 2723 attribute. Values include: 2725 0: undefined 2726 1: String 2727 2: GUID 2728 3: UUID 2729 4: URI 2730 5: FQDN 2732 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" 2734 This is an optional array of string attributes that identifies the 2735 set of policy actions to take if the SUPAPolicyStructure object 2736 that owns this association failed to execute properly. The 2737 interpretation of this string attribute is defined by the 2738 supaPolExecFailTakeActionEncoding class attribute. The association 2739 defines the SUPAPolicyStructure that contains the set of policy 2740 actions to execute, and this attribute defines which of these 2741 actions are to be executed. Note that there is no need to execute 2742 a SUPAPolicy, since the event and failure have already occurred. 2744 5.3.2.7. The Aggregation "SUPAHasPolicyClause" 2746 This is an optional aggregation that defines the set of 2747 SUPAPolicyClauses that are aggregated by this particular 2748 SUPAPolicyStructure instance. The semantics of this 2749 aggregation are defined by the SUPAHasPolicyClauseDetail 2750 association class. 2752 Every SUPAPolicyStructure object instance MUST aggregate at 2753 least one SUPAPolicyClause object instance. However, the 2754 converse is NOT true. For example, a SUPAPolicyClause could be 2755 instantiated and then stored for later use in a policy repository. 2756 Furthermore, the same SUPAPolicyClause could be used by zero or 2757 more SUPAPolicyStructure object instances at a given time. Thus, 2758 the multiplicity of this aggregation is defined as 0..1 on the 2759 aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the 2760 part (i.e., the SUPAPolicyClause side). This means that at 2761 least one SUPAPolicyClause MUST be aggregated by this 2762 SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may 2763 be aggregated by this particular SUPAPolicyStructure object. 2765 5.3.2.8. The Association Class "SUPAHasPolicyClauseDetail" 2767 This is an optional association class, and defines the semantics 2768 of the SUPAHasPolicyClause aggregation. The attributes and/or 2769 relationships of this association class can be used to determine 2770 which SUPAPolicyClauses are aggregated by which 2771 SUPAPolicyStructure objects. 2773 Attributes will be added to this class at a later time. 2775 5.4. The Abstract Class "SUPAPolicyComponentStructure" 2777 This is a mandatory abstract class that is the superclass of all 2778 objects that represent different types of components of a 2779 SUPAPolicy. Different types of policies have different types of 2780 structural components. However, all of these are used in at least 2781 one type of policy. This class represents a convenient control 2782 point for defining characteristics and behavior that are common 2783 to objects that serve as components of a policy. 2785 Note that there are significant differences between the definition 2786 of this class, and its attributes, and the definition of the 2787 corresponding class (and its attributes) in [5]. 2789 5.4.1. SUPAPolicyComponentStructure Attributes 2791 No attributes are currently defined for the 2792 SUPAPolicyComponentStructure class. 2794 5.4.2. SUPAPolicyComponentStructure Relationships 2796 SUPAPolicyComponentStructure participates in a single relationship, 2797 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 2799 5.5. The Abstract Class "SUPAPolicyClause" 2801 This is a mandatory abstract class that separates the 2802 representation of a SUPAPolicy from its implementation. 2803 SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction 2804 is missing in [RFC3060], [RFC3460], [4], and [6]. This class is 2805 called PolicyStatement in [5], but the class and relationship 2806 definitions differ significantly from the corresponding designs 2807 in this document. 2809 A SUPAPolicyClause contains an individual or group of related 2810 functions that are used to define the content of a policy. More 2811 specifically, since the number and type of functions that make up 2812 a SUPAPolicyClause can vary, the decorator pattern is used, so 2813 that the contents of a SUPAPolicyClause can be adjusted 2814 dynamically at runtime without affecting other objects. 2816 This document defines two different types of policy clauses: 2817 SUPAEncodedClause (which is generic, and can be used by any 2818 type of policy), and SUPABooleanClause (which is also generic, 2819 but is typically used by SUPAECAPolicyRule objects). 2821 SUPAPolicyClauses are objects in their own right, which 2822 facilitates their reuse. SUPAPolicyClauses can aggregate a set 2823 of any of the subclasses of SUPAPolicyComponentDecorator, which 2824 was shown in Figure 10. These four subclasses provide four 2825 different ways to construct a SUPAPolicyClause: 2827 1) SUPAPolicyTerm, which enables constructing a {variable, 2828 operator, value} expression for building DUPAPolicyClauses 2829 2) SUPAEncodedClause, which enables policy clauses to be 2830 formed as an encoded object (e.g., to pass YANG or CLI code) 2831 3) SUPAPolicyCollection, which defines a collection of objects 2832 that requires further processing by the policy management 2833 system in order to be made into a SUPAPolicyClause 2834 4) SUPAECAComponent, which enables policy clauses to be formed 2835 using (reusable) Event, Condition, and/or Action objects 2837 SUPAPolicyClauses are aggregated by a SUPAPolicyStructure 2838 object, which enables all types of SUPAPolicies to uniformly be 2839 made up of one or more SUPAPolicyClauses. 2841 5.5.1. SUPAPolicyClause Attributes 2843 This section defines the attributes of the SUPAPolicyClause 2844 class, which are inherited by all SUPAPolicyClause subclasses. 2846 5.5.1.1. The Attribute "supaPolClauseExecStatus" 2848 This is an optional enumerated non-negative integer attribute. It 2849 defines whether this SUPAPolicyClause is currently in use and, if 2850 so, what its execution status is. This attribute can also be used 2851 to place this particular SUPAPolicyClause into a specific execution 2852 state, such as enabled (values 1-4), in test (value 5) or disabled 2853 (value 6). Values include: 2855 0: Unknown (an error state) 2856 1: Completed (i.e., successfully executed, but now idle) 2857 2: Working (i.e., in use and no errors reported) 2858 3: Not Working (i.e., in use, but errors have been reported) 2859 4: Available (i.e., could be used, but currently isn't) 2860 5: In Test (i.e., cannot be used as part of an OAM&P policy) 2861 6: Disabled (i.e., not available for use) 2863 Value 0 denotes an error that prevents this SUPAPolicyClause 2864 from being used. Value 1 means that this SUPAPolicyClause has 2865 successfully finished execution, and is now idle. Value 2 means 2866 that this SUPAPolicyClause is in use; in addition, this 2867 SUPAPolicyClause is working correctly. Value 3 is the same as 2868 value 2, except that this SUPAPolicyClause is not working 2869 correctly. Value 4 means that this SUPAPolicyClause is available, 2870 but not currently in use. Value 5 means that this SUPAPolicyClause 2871 is in a special test state. A test state signifies that it SHOULD 2872 NOT be used to evaluate OAM&P policies. A value of 6 means that 2873 this SUPAPolicyClause is unavailable for use. 2875 5.5.2. SUPAPolicyClause Relationships 2877 SUPAPolicyClause participates in a single relationship, 2878 SUPAHasPolicyClause, as defined in section 5.3.2.7. Note that 2879 SUPAPolicyClause uses the decorator pattern to "wrap" this object 2880 with instances of the (concrete) subclasses of the 2881 SUPAPolicyComponentDecorator object. 2883 5.6. The Concrete Class "SUPAEncodedClause" 2885 This is a mandatory concrete class that refines the behavior of a 2886 SUPAPolicyClause. 2888 This class defines a generalized extension mechanism for 2889 representing SUPAPolicyClauses that have not been modeled 2890 with other SUPAPolicy objects. Rather, the contents of the policy 2891 clause are directly encoded into the attributes of the 2892 SUPAEncodedClause. Hence, SUPAEncodedClause objects are reusable 2893 at the object level, whereas SUPABooleanClause clauses are reusable 2894 at the individual Boolean expression level. 2896 This class uses two of its attributes (supaEncodedClauseContent and 2897 supaEncodedClauseEncoding) for defining the content and type of 2898 encoding used in a given SUPAPolicyClause. The benefit of a 2899 SUPAEncodedClause is that it enables direct encoding of the text of 2900 the SUPAPolicyClause, without having the "overhead" of using other 2901 objects. However, note that while this method is efficient, it 2902 does not reuse other SUPAPolicy objects. 2904 5.6.1. SUPAEncodedClause Attributes 2906 This section defines the attributes of the SUPAEncodedClause class. 2908 5.6.1.1. The Attribute "supaEncodedClauseContent" 2910 This is a mandatory string attribute, and defines the content of 2911 this clause. It works with another class attribute, called 2912 supaEncodedClauseEncoding, which defines how to interpret the 2913 value of this attribute (e.g., as a string or reference). These 2914 two attributes form a tuple, and together enable a machine to 2915 understand the syntax and value of this object instance. 2917 5.6.1.2. The Attribute "supaEncodedClauseEncoding" 2919 This is a mandatory integer attribute, and defines how to 2920 interpret the value of this encoded clause. It works with another 2921 class attribute, called supaEncodedClauseContent, which defines 2922 the content of the encoded clause. These two attributes form a 2923 tuple, and together enable a machine to understand the syntax and 2924 value of the encoded clause for the object instance of this class. 2925 Values include: 2927 0: undefined 2928 1: String 2929 2: GUID 2930 3: UUID 2931 4: URI 2932 5: FQDN 2934 5.6.1.3. The Attribute "supaEncodedClauseResponse" 2936 This is an optional Boolean attribute that emulates a Boolean 2937 response of this clause, so that it may be combined with other 2938 subclasses of the SUPAPolicyClause that provide a status as to 2939 their correctness and/or evaluation state. This enables this 2940 object to be used to construct more complex Boolean clauses. 2942 5.6.2. SUPAEncodedClause Relationships 2944 SUPAPolicyClause participates in a single inherited relationship, 2945 SUPAHasPolicyClause, as defined in section 5.3.2.7. 2947 5.7. The Abstract Class "SUPAPolicyComponentDecorator" 2949 This is a mandatory class, and is used to implement the decorator 2950 pattern. The decorator pattern enables all or part of one or more 2951 objects to "wrap" another concrete object. This means that any 2952 any concrete subclass of SUPAPolicyClause is wrapped by any 2953 concrete subclass of SUPAPolicyComponentDecorator, as shown in 2954 Figure 19 below. 2956 A 2957 +------------------------------+ 2958 | | 1..n 2959 | SUPAPolicyComponentStructure +--------+ 2960 | | | used to wrap 2961 +------------------------------+ | concrete 2962 / \ | subclasses of 2963 I | PolicyClause 2964 I | 2965 +---------------+--------------+ / \ 2966 I I A 2967 A I A I \ / 0..1 2968 +----------+---------+ +--------------+-----+---------+ 2969 | SUPAPolicyClause | | SUPAPolicyComponentDecorator | 2970 +----------+---------+ +--------------+---------------+ 2971 I I 2972 I I 2973 / \ / \ 2974 Concrete Subclasses, Concrete Subclasses 2975 (e.g., SUPAEncodedClause) (e.g., SUPAPolicyCollection) 2976 (object being wrapped) (wrapping object(s)) 2978 Figure 19. The PolicyComponent Decorator Pattern 2980 5.7.1. The Decorator Pattern 2982 Each SUPAPolicyComponentDecorator object HAS_A (i.e., wraps) a 2983 concrete instance of the SUPAPolicyClause object. This means that 2984 the SUPAPolicyComponentDecorator object has an instance variable 2985 that holds a reference to a SUPAPolicyClause object. Since the 2986 SUPAPolicyComponentDecorator object has the same interface as the 2987 SUPAPolicyClause object, the SUPAPolicyComponentDecorator object 2988 (and all of its subclasses) are transparent to clients of the 2989 SUPAPolicyClause object (and its subclasses). This means that 2990 SUPAPolicyComponentDecorator object instances can add attributes 2991 and/or methods to those of the concrete instance of the chosen 2992 subclass of SUPAPolicyClause. 2994 Figure 19 shows how this is done for methods. 19a shows the 2995 initial object to be wrapped; 19b shows SUPAPolicyCollection 2996 wrapping SUPAEncodedClause; 19c shows SUPAVendorDecoratedComponent 2997 wrapping SUPAPolicyCollection. 2999 +-------------------+ 3000 | SUPAEncodedClause | 3001 | eval() | 3002 +-------------------+ 3003 (a) Initial Object 3005 ===> 3006 +------------------------+ 3007 | SUPAPolicyCollection | 3008 | eval() | 3009 | +-------------------+ | 3010 | | SUPAEncodedClause | | 3011 | | eval() | | 3012 | +-------------------+ | 3013 +------------------------+ 3014 (b) SUPAPolicyCollection "wraps" SUPAEncodedClause 3016 ===> 3017 +------------------------------+ 3018 | SUPAVendorDecoratedComponent | 3019 | eval() | 3020 | +-----------------------+ | 3021 | | SUPAPolicyCollection | | 3022 | | eval() | | 3023 | | +-------------------+ | | 3024 | | | SUPAEncodedClause | | | 3025 | | | eval() | | | 3026 | | +-------------------+ | | 3027 | +-----------------------+ | 3028 +------------------------------+ 3029 (c) SUPAVendorDecoratedComponent "wraps" SUPAPolicyCollection 3031 Figure 20. Conceptual Depiction of eval() Decorated Method 3033 When eval() is called in the outermost object 3034 (SUPAVendorDecoratedComponent), it delegates to the eval() method 3035 of SUPAPolicyCollection, which in turn delegates to the eval() 3036 method of SUPAEncodedClause. This method executes and returns the 3037 results to SUPAPolicyCollection, which executes and returns the 3038 results to SUPAVendorDecoratedComponent, which executes and returns 3039 the final result. 3041 5.7.2. SUPAPolicyComponentDecorator Attributes 3043 Currently, there are two attributes defined for this class, which 3044 are described in the following subsections. Both attributes are 3045 used by subclasses to constrain the behavior of that subclass; 3046 they do **not** affect the relationship between the concrete 3047 subclass of SUPAPolicyComponentDecorator that is wrapping the 3048 concrete subclass of SUPAPolicyClause. This is different 3049 than the use of similar attributes defined in the 3050 SUPAHasDecoratedPolicyComponentDetail association class (which 3051 are used to constrain the relationship between the concrete 3052 subclass of SUPAPolicyClause and the concrete subclass of the 3053 SUPAHasDecoratedPolicyComponent object that is wrapping it). 3054 Note that [2] does not define any attributes for this class. 3056 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" 3058 This is a mandatory non-negative enumerated integer that defines 3059 how to interpret each string in the supaPolCompConstraint class 3060 attribute. Values include: 3062 0: undefined 3063 1: OCL 2.4 3064 2: OCL 2.x 3065 3: OCL 1.x 3066 4: QVT 1.2 - Relations Language 3067 5: QVT 1.2 - Operational language 3068 6: Alloy 3070 Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the 3071 latest version as of this writing). QVT defines a set of languages 3072 (the two most powerful and useful are defined by enumerations 4 3073 and 5). Alloy is a language for describing constraints, and uses a 3074 SAT solver to guarantee correctness. 3076 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" 3078 This is a mandatory array of string attributes. Each attribute 3079 specifies a constraint to be applied using the encoding defined in 3080 the supaPolCompConstraintEncoding class attribute. This provides 3081 a more rigorous and flexible treatment of constraints than is 3082 possible in [RFC3460]. 3084 5.7.3. SUPAPolicyComponentDecorator Relationships 3086 One relationship is currently defined for this class, which is 3087 described in the following subsection. 3089 5.7.3.1. The Aggregation "SUPAHasDecoratedPolicyComponent" 3091 This is a mandatory aggregation, and is part of a decorator 3092 pattern. It is used to enable a concrete instance of a 3093 SUPAPolicyComponentDecorator to dynamically add behavior to a 3094 specific type of SUPAPolicyClause object. The semantics of this 3095 aggregation are defined by the 3096 SUPAHasDecoratedPolicyComponentDetail association class. 3098 5.7.3.2. The Association Class 3099 "SUPAHasDecoratedPolicyComponentDetail" 3101 This is a mandatory concrete association class, and defines the 3102 semantics of the SUPAHasDecoratedPolicyComponent aggregation. The 3103 purpose of this class is to use the Decorator pattern to determine 3104 which SUPAPolicyComponentDecorator object instances, if any, are 3105 required to augment the functionality of the concrete subclass of 3106 SUPAPolicyClause that is being used. 3108 Currently, there are two attributes defined for this class, which 3109 are described in the following subsections. Both attributes are 3110 used in this association class to constrain the **relationship** 3111 between the concrete subclass of SUPAPolicyComponentDecorator that 3112 is wrapping the concrete subclass of SUPAPolicyClause. Note that 3113 class attributes of SUPAPolicyComponentDecorator (see section 3114 5.9.2) only affect that specific subclass. 3116 5.7.3.2.1. The Attribute "supaDecoratedConstraintEncoding" 3118 This is a mandatory non-negative enumerated integer that defines 3119 how to interpret each string in the supaDecoratedConstraint class 3120 attribute. Values include: 3122 0: undefined 3123 1: OCL 2.4 3124 2: OCL 2.x 3125 3: OCL 1.x 3126 4: QVT 1.2 - Relations Language 3127 5: QVT 1.2 - Operational language 3128 6: Alloy 3130 Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the 3131 latest version as of this writing). QVT defines a set of languages 3132 (the two most powerful and useful are defined by enumerations 4 3133 and 5). Alloy is a language for describing constraints, and uses a 3134 SAT solver to guarantee correctness. 3136 5.7.3.2.2. The Attribute "supaDecoratedConstraint[0..n]" 3138 This is a mandatory array of string attributes. Its purpose is to 3139 collect a set of constraints to be applied to a decorated object. 3140 The interpretation of each constraint in the array is defined in 3141 the supaDecoratedConstraintsEncoding class attribute. 3143 5.7.4. Illustration of Constraints in the Decorator Pattern 3145 The following example will illustrate how the different constraints 3146 defined in sections 5.7.2 (class attribute constraints) and section 3147 5.7.3 (relationship constraints) can be used. 3149 Figure 21 builds a simple SUPAPolicyClause that has both types 3150 of relationships. 3152 A A 3153 +------------------+ 0..1 +----------------------------+ 3154 | | 1..n / \| | 3155 | SUPAPolicyClause +------+----- A +SUPAPolicyComponentDecorator| 3156 | | ^ \ /| | 3157 +---------+--------+ | +-----------+----------------+ 3158 I | I 3159 I | I 3160 C I | C I 3161 +--------+--------+ | +---------+----------+ 3162 |SUPAEncodedClause| | |SUPAPolicyCollection| 3163 +-----------------+ | +--------------------+ 3164 | 3165 C | 3166 +-----------------+-------------------+ 3167 |SUPAHasDecoratedPolicyComponentDetail| 3168 +-------------------------------------+ 3170 Figure 21. Constraints in the Decorator Pattern 3172 Figure 21 says that a SUPAPolicyClause, realized as a 3173 SUPAEncodedClause, is wrapped by a SUPAPolicyCollection object. 3174 The attributes in the SUPAPolicyComponentDecorator object are used 3175 to constrain the attributes in the SUPAPolicyCollection object, 3176 while the attributes in the SUPAHasDecoratedPolicyComponentDetail 3177 object are used to contrain the behavior of the aggregation 3178 (SUPAHasDecoratedPolicyComponent). For example, the attributes in 3179 the SUPAPolicyComponentDecorator object could restrict the data 3180 type and range of the components in the SUPAPolicyCollection, while 3181 the attributes in the SUPAHasDecoratedPolicyComponentDetail object 3182 could restrict which SUPAPolicyCollection objects are allowed to be 3183 used with which SUPAEncodedClauses. 3185 5.8. The Abstract Class "SUPAPolicyTerm" 3187 This is a mandatory abstract class that is the parent of 3188 SUPAPolicy objects that can be used to define a standard way to 3189 test or set the value of a variable. It does this by defining a 3190 3-tuple, in the form {variable, operator, value}, where each 3191 element of the 3-tuple is defined by a concrete subclass of the 3192 appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator, 3193 and SUPAPolicyValue classes, respectively). For example, a 3194 generic test or set of the value of a variable is expressed as: 3196 {variable, operator, value}. 3198 For event and condition clauses, this is typically as written above 3199 (e.g., does variable = value); for action clauses, it is typically 3200 written as (e.g., SET var to 1). A 3201 class diagram is shown in Figure 22. 3203 A 3204 +----------------+ 3205 | SUPAPolicyTerm | 3206 +--------+-------+ 3207 / \ 3208 I 3209 I 3210 I 3211 +-----------------+---+--------------------+ 3212 I I I 3213 I I I 3214 C I C I C I 3215 +--------+---------+ +--------+---------+ +-------+-------+ 3216 |SUPAPolicyVariable| |SUPAPolicyOperator| |SUPAPolicyValue| 3217 +------------------+ +------------------+ +---------------+ 3219 Figure 22. SUPAPolicyTerm Class Hierarchy 3221 Note that generic test and set expressions do not have to only use 3222 objects that are subclasses of SUPAPolicyTerm. For example, the 3223 polVendorDecoratedContent attribute of the 3224 SUPAVendorDecoratedComponent could be used as the variable (or the 3225 value) term of a get or set expression. 3227 Hence, the utility of the subclasses of SUPAPolicyTerm is in the 3228 ability of its subclasses to define a generic framework for 3229 implementing get and set expressions. This is in contrast to 3230 previous designs (e.g., [RFC3460] and [6]), which depended on 3231 defining a broad set of subclasses of PolicyVariable and 3232 PolicyValue. (Note that [4] does not have this generic capability). 3234 5.8.1. SUPAPolicyTerm Attributes 3236 Currently, SUPAPolicyTerm defines a single attribute, as described 3237 in the following subsection. Constraints on the subclasses of 3238 SUPAPolicyTerm can be applied in two different ways: 3240 1. use SUPAPolicyComponentDecorator attributes to constrain 3241 just that individual subclass, and/or 3242 2. use SUPAHasDecoratedPolicyComponentDetail association class 3243 attributes to constrain the relationship between the concrete 3244 subclass of SUPAPolicyClause and the concrete subclass of 3245 the SUPAPolicyTerm class 3247 5.8.1.1. The Attribute "supaPolTermIsNegated" 3249 This is a mandatory Boolean attribute. If the value of this 3250 attribute is true, then this particular SUPAPolicyTerm subclass 3251 (which represents a term) is negated; otherwise, it is not. 3253 5.8.2. SUPAPolicyTerm Relationships 3255 Currently, no dedicated relationships are defined for the 3256 SUPAPolicyTerm class (as there are in [RFC3460] and [6]) that 3257 aggregate policy variable and policy value objects into a policy 3258 rule). This is: 3260 1) to enable the subclasses of SUPAPolicyTerm to be used by 3261 other SUPAPolicyComponentDecorator objects, and 3262 2) because the decorator pattern replaces how such relationships 3263 were used in [RFC3460] and [6]. 3265 SUPAPolicyTerm, and its subclasses, inherit the 3266 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3267 section 5.7.3. 3269 5.9. The Concrete Class "SUPAPolicyVariable" 3271 This is a mandatory concrete class that defines information that 3272 forms a part of a SUPAPolicyClause. It specifies a concept or 3273 attribute that represents a variable, which should be compared to 3274 a value, as specifed in this SUPAPolicyClause. If it is used in 3275 a SUPAECAPolicyRule, then its value MAY be able to be changed at 3276 any time, including run-time, via use of the decorator pattern. 3277 Note that this is not possible in previous designs ([RFC3460, [4], 3278 and [6]). 3280 The value of a SUPAPolicyVariable is typically compared to the 3281 value of a SUPAPolicyValue using the type of operator defined in 3282 a SUPAPolicyOperator. However, other objects may be used instead 3283 of a SUPAPolicyValue object, and other operators may be defined 3284 in addition to those defined in the SUPAPolicyOperator class. 3286 SUPAPolicyVariables are used to abstract the representation of a 3287 SUPAPolicyRule from its implementation. Some SUPAPolicyVariables 3288 are restricted in the values and/or the data type that they may 3289 be assigned. For example, port numbers cannot be negative, and 3290 they cannot be floating-point numbers. These and other constraints 3291 may be defined in two different ways: 3293 1. use SUPAPolicyComponentDecorator attributes to constrain 3294 just that individual subclass, and/or 3295 2. use SUPAHasDecoratedPolicyComponentDetail association class 3296 attributes to constrain the relationship between the concrete 3297 subclass of SUPAPolicyClause and the concrete subclass of 3298 the SUPAPolicyVariable class 3300 Please refer to the examples in section 7, which show how to 3301 restrict the value, data type, range, and other semantics of the 3302 SUPAPolicyVariable when used in a SUPAPolicyClause. 3304 5.9.1. Problems with the RFC3460 Version of PolicyValue 3306 Please see Appendix A for a detailed comparison. 3308 5.9.2. SUPAPolicyVariable Attributes 3310 SUPAPolicyVariable defines one attribute, as described below. 3312 5.9.2.1. The Attribute "supaPolVarName" 3314 This is an optional string attribute that contains the name of 3315 this SUPAPolicyVariable. This variable name forms part of the 3316 {variable, operator, value} canonical form of a SUPAPolicyClause. 3318 5.9.3. SUPAPolicyVariable Relationships 3320 Currently, no relationships are defiend for the SUPAPolicyVariable 3321 class (note that the decorator pattern obviates the need for 3322 relationships such as those in [RFC3460] and [6]). 3323 SUPAPolicyVariable, and its subclasses, inherit the 3324 SUPAHasDecoratedPolicyComponent aggregation, which was defined in 3325 section 5.7.3. 3327 5.10. The Concrete Class "SUPAPolicyOperator" 3329 This is a mandatory concrete class for modeling different types of 3330 operators that are used in a SUPAPolicyClause. 3332 The restriction of the type of operator used in a SUPAPolicyClause 3333 restricts the semantics that can be expressed in that 3334 SUPAPolicyClause. It is typically used with SUPAPolicyVariables 3335 and SUPAPolicyValue to form a SUPAPolicyClause. 3337 5.10.1. Problems with the RFC3460 Version 3339 Please see Appendix A for a detailed comparison. 3341 5.10.2. SUPAPolicyOperator Attributes 3343 Currently, SUPAPolicyOperator defines a single generic attribute, 3344 as described below. 3346 5.10.2.1. The Attribute "supaPolOpType" 3348 This is a mandatory non-negative enumerated integer that specifies 3349 the various types of operators that are allowed to be used in this 3350 particular SUPAPolicyClause. Values include: 3352 0: Unknown 3353 1: Greater than 3354 2: Greater than or equal to 3355 3: Less than 3356 4: Less than or equal to 3357 5: Equal to 3358 6: Not equal to 3359 7: IN 3360 8: NOT IN 3361 9: SET 3362 10: CLEAR 3363 11: BETWEEN 3365 Note that 0 is an unacceptable value. Its purpose is to support 3366 dynamically building a SUPAPolicyClause by enabling the 3367 application to set the value of this attribute to a standard 3368 default value if the real value is not yet known. 3370 Additional operators may be defined in future work. For example, 3371 if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from 3372 include structured objects, then "deep" versions of operators 3373 1-6 could also be defined. In this case, values 1-6 will be 3374 edited to explicitly indicate that they perform "shallow" 3375 comparison operations. 3377 5.10.3. SUPAPolicyOperator Relationships 3379 Currently, no relationships are defiend for the SUPAPolicyOperator 3380 class (note that the decorator pattern obviates the need for 3381 relationships such as those in [6]). SUPAPolicyOperator, and its 3382 subclasses, inherit the SUPAHasDecoratedPolicyComponent 3383 aggregation, which was defined in section 5.7.3. 3385 Please refer to the examples in section 7, which show how to 3386 restrict the value, data type, range, and other semantics of the 3387 SUPAPolicyOperator when used in a SUPAPolicyClause. 3389 5.11. The Concrete Class "SUPAPolicyValue" 3391 The SUPAPolicyValue class is a mandatory concrete class for 3392 modeling different types of values and constants that occur in a 3393 SUPAPolicyClause. 3395 SUPAPolicyValues are used to abstract the representation of a 3396 SUPAPolicyRule from its implementation. Therefore, the design of 3397 SUPAPolicyValues depends on two important factors. First, just as 3398 with SUPAPolicyVariables (see Section 5.11), some types of 3399 SUPAPolicyValues are restricted in the values and/or the data 3400 type that they may be assigned. Second, there is a high likelihood 3401 that specific applications will need to use their own variables 3402 that have specific meaning to a particular application. 3404 In general, there are two ways to apply constraints to an object 3405 instance of a SUPAPolicyValue: 3407 1. use SUPAPolicyComponentDecorator attributes to constrain 3408 just that individual subclass, and/or 3409 2. use SUPAHasDecoratedPolicyComponentDetail association class 3410 attributes to constrain the relationship between the concrete 3411 subclass of SUPAPolicyClause and the concrete subclass of 3412 the SUPAPolicyValue class 3414 The value of a SUPAPolicyValue is typically compared to the value 3415 of a SUPAPolicyVariable using the type of operator defined in 3416 a SUPAPolicyOperator. However, other objects may be used instead 3417 of a SUPAPolicyVariable object, and other operators may be defined 3418 in addition to those defined in the SUPAPolicyOperator class. 3420 5.11.1. Problems with the RFC3460 Version of PolicyValue 3422 Please see Appendix A for a detailed comparison. 3424 5.11.2. SUPAPolicyValue Attributes 3426 Currently, SUPAPolicyValue defines two generic attributes, as 3427 described below. 3429 5.11.2.1. The Attribute "supaPolValContent[0..n]" 3431 This is a mandatory attribute that defines an array of strings. 3432 The array contains the value(s) of this SUPAPolicyValue object 3433 instance. Its data type is defined by the supaPolValEncoding 3434 class attribute. 3436 5.11.2.2. The Attribute "supaPolValEncoding" 3438 This is a mandatory string attribute that contains the data type 3439 of the SUPAPolicyValue object instance. Its value is defined by 3440 the supaPolValContent class attribute. Values include: 3442 0: Undefined 3443 1: String 3444 2: Integer 3445 3: Boolean 3446 4: Floating Point 3447 5: DateTime 3448 6: GUID 3449 7: UUID 3450 8: URI 3451 9: FQDN 3452 10: NULL 3454 A string is a sequence of zero or more characters. An Integer is 3455 a whole number (e.g., it has no fractional part). A Boolean 3456 represents the values TRUE and FALSE. A floating point number may 3457 contain fractional values, as well as an exponent. A DateTime 3458 represents a value that has a date and/or a time component (as in 3459 the Java or Python libraries). A NULL explicitly models the lack 3460 of a value. 3462 5.11.3. SUPAPolicyValue Relationships 3464 Currently, no relationships are defiend for the SUPAPolicyValue 3465 class (note that the decorator pattern obviates the need for 3466 relationships such as those in [6]). SUPAPolicyValue, and its 3467 subclasses, inherit the SUPAHasDecoratedPolicyComponent 3468 aggregation, which was defined in section 5.7.3. 3470 Please refer to the examples in section 7, which show how to 3471 restrict the value, data type, range, and other semantics of the 3472 SUPAPolicyValue when used in a SUPAPolicyClause. 3474 5.12. The Concrete Class "SUPAVendorDecoratedComponent" 3476 A SUPAVendorDecoratedComponent enables a custom, vendor-specific 3477 object to be defined and used in a SUPAPolicyClause. This class 3478 was derived from [2], but is not present in [RFC3460], [4], [5], 3479 or [6]. 3481 This should not be confused with the SUPAEncodedClause class. The 3482 SUPAVendorDecoratedComponent class represents a single, atomic, 3483 that is vendor-specific object that defines a **portion** of a 3484 SUPAPolicyClause, whereas a SUPAEncodedClause, which may or 3485 may not be vendor-specific, represents an **entire** 3486 SUPAPolicyClause. 3488 5.12.1. SUPAVendorDecoratedComponent Attributes 3490 Currently, SUPAVendorDecoratedComponent defines two generic 3491 attributes, as described below. 3493 5.12.1.1. The Attribute "supaVendorDecoratedCompContent[0..n]" 3495 This is a mandatory attribute that defines an array of strings. 3496 This array contains the value(s) of the 3497 SUPAVendorDecoratedComponent object instance. Its data type is 3498 defined by the supaVendorDecoratedEncoding class attribute. 3500 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 3502 This is a mandatory integer attribute that defines the format of 3503 the supaVendorDecoratedContent class attribute. Values include: 3505 0: undefined 3506 1: String 3507 2: Integer 3508 3: Boolean 3509 4: Floating Point 3510 5: DateTime 3511 6: GUID 3512 7: UUID 3513 8: URI 3514 9: FQDN 3515 10: NULL 3517 A string is a sequence of zero or more characters. An Integer is 3518 a whole number (e.g., it has no fractional part). A Boolean 3519 represents the values TRUE and FALSE. A floating point number may 3520 contain fractional values, as well as an exponent. A DateTime 3521 represents a value that has a date and/or a time component (as in 3522 the Java or Python libraries). A NULL explicitly models the lack 3523 of a value. 3525 5.12.2. SUPAVendorDecoratedComponent Relationships 3527 Currently, no relationships are defiend for the 3528 SUPAVendorDecoratedComponent class (note that the decorator 3529 pattern obviates the need for relationships such as those in [6]). 3530 SUPAVendorDecoratedComponent participates in a single relationship, 3531 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 3533 5.13. The Concrete Class "SUPAPolicyCollection" 3535 A SUPAPolicyCollection is an optional concrete class that enables 3536 a collection (e.g., set, bag, or other, more complex, collections 3537 of elements) of **arbitrary objects** to be defined and used as 3538 part of a SUPAPolicyClause. This class was derived from [2], but 3539 is not present in [RFC3460], [4], [5], or [6]. 3541 5.13.1. Motivation 3543 One of the problems with ECA policy rules is when a set of events 3544 or conditions needs to be tested. For example, if a set of events 3545 is received, the policy system may need to wait for patterns of 3546 events to emerge (e.g., any number of Events of type A, followed 3547 by either one event of type B or two events of type Event C). 3549 Similarly, a set of conditions, testing the value of an attribute, 3550 may need to be performed. Both of these represent behavior 3551 similar to a set of if-then-else statements or a switch statement. 3553 It is typically not desirable for the policy system to represent 3554 each choice in such conditions as its own policy clause (i.e., a 3555 3-tuple), as this creates object explosion and poor performance. 3556 Furthermore, in these cases, it is often required to have a set of 3557 complex logic to be executed, where the logic varies according to 3558 the particular event or condition that was selected. It is much 3559 too complex to represent this using separate objects, especially 3560 when the logic is application- and/or vendor-specific. 3562 However, recall that one of the goals of this document was to 3563 facilitate the machine-driven construction of policies. Therefore, 3564 a solution to this problem is needed. 3566 5.13.2. Solution 3568 Therefore, this document defines the concept of a collection of 3569 entities, called a SUPAPolicyCollection. Conceptually, the items 3570 to be collected (e.g., events or conditions) are aggregated in 3571 one or more SUPAPolicyCollection objects of the appropriate type. 3572 Another optional SUPAPolicyCollection object could be used to 3573 aggregate logic blocks (including SUPAPolicies) to execute. 3574 Once finished, all appropriate SUPAPolicyCollection objects are 3575 sent to an external system for evaluation. 3577 The computation(s) represented by the SUPAPolicyCollection may be 3578 part of a larger SUPAPolicyClause, since SUPAPolicyCollection is a 3579 subclass of SUPAPolicyComponentDecorator, and can be used to 3580 decorate a SUPAPolicyClause. Therefore, the external system is 3581 responsible for providing a Boolean TRUE or FALSE return value, so 3582 that the policy system can use that value to represent the 3583 computation of the function(s) performed in the 3584 SUPAPolicyCollection in a Boolean clause. 3586 5.13.3. SUPAPolicyCollection Attributes 3588 Currently, SUPAVendorDecoratedComponent defines five attributes, 3589 as described below. 3591 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 3593 This is an optional attribute that defines an array of strings. 3594 Each string in the array identifies a domain-suitable identifier of 3595 an object that is collected by this SUPAPolicyCollection instance. 3597 5.13.3.2. The Attribute "supaPolCollectionEncoding" 3599 This is an optional non-negative enumerated integer that defines 3600 the data type of the content of this collection instance. Values 3601 include: 3603 0: undefined 3604 1: by regex (regular expression) 3605 2: by URI 3607 For example, if the value of this attribute is 1, then each of 3608 the strings in the supaPolCollectionContent attribute represent 3609 a regex that contains all or part of a string to match the class 3610 name of the object that is to be collected by this instance of 3611 a SUPAPolicyCollection class. 3613 5.13.3.3. The Attribute "supaPolCollectionFunction" 3615 This is an optional non-negative enumerated integer that defines 3616 the function of this collection instance. Values include: 3618 0: undefined 3619 1: event collection 3620 2: condition collection 3621 3: action collection 3622 4: logic collection 3624 Values 1-3 define a collection of objects that are to be used to 3625 populate the event, condition, or action clauses, respectively, of 3626 a SUPAECAPolicyRule. A value of 4 indicates that this collection 3627 contains objects that define logic for processing a SUPAPolicy. 3629 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" 3631 This is an optional Boolean attribute. If the value of this 3632 attribute is TRUE, then all elements in this instance of this 3633 SUPAPolicyCollection are ordered. 3635 5.13.3.5. The Attribute "supaPolCollectionType" 3637 This is an optional non-negative enumerated integer that defines 3638 the type of collection that this instance is. Values include: 3640 0: undefined 3641 1: set 3642 2: bag (e.g., multi-set) 3643 3: dictionary (e.g., associative array) 3645 A set is an unordered collection of elements that MUST NOT have 3646 duplicates. A bag is an unordered collection of elements; it MAY 3647 also have duplicates. A dictonary is a table that associates a 3648 key with a value. 3650 Sets have a number of important functions, including: 3652 o membership: returns TRUE if the element being tested is 3653 in the set, and FALSE otherwise 3654 o subset: returns TRUE if all elements in the first set 3655 are also in the second set 3656 o union: returns all elements from both sets with no 3657 duplicates 3658 o intersection: returns all elements that are in both sets 3659 with no duplicates 3660 o difference: returns all elements in the first set that 3661 are not in the second set 3663 Bags have a number of important functions in addition to the 3664 functions defined for sets (note that while the above set of 3665 functions for a set and a bag are the same, a bag is a different 3666 data type than a set): 3668 o multiplicity: returns the number of occurrences of an 3669 element in the bag 3670 o count: returns the number of all items, including 3671 duplicates 3672 o countDistinct: returns the number of items, where all 3673 duplicates are ignored 3675 A dictionary is an unordered set of key:value pairs, where each 3676 key is unique within a given dictionary. The combination of a 3677 key and a value is called an item. The format of an item is 3678 defined as one element (the key) followed by a colon followed 3679 by a second element (the value). Each item in a set of items is 3680 separated by a comma. Keys MUST NOT be NULL; values MAY be NULL. 3682 An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}. 3683 An example of a null dictionary is simply {}. 3685 5.13.4. SUPAPolicyCollection Relationships 3687 Currently, no relationships are defiend for the 3688 SUPAVendorDecoratedComponent class (note that the decorator 3689 pattern obviates the need for relationships such as those in [6]). 3690 SUPAPolicyCollection participates in a single relationship, 3691 SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 3693 5.14. The Concrete Class "SUPAPolicySource" 3695 This is an optional class that defines a set of managed entities 3696 that authored, or are otherwise responsible for, this 3697 SUPAPolicyClause. Note that a SUPAPolicySource does NOT 3698 evaluate or execute SUPAPolicies. Its primary use is for 3699 auditability and the implementation of deontic and/or alethic logic. 3700 A class diagram is shown in Figure 12. 3702 A SUPAPolicySource SHOULD be mapped to a role or set of roles 3703 (e.g., using the role-object pattern [11]). This enables 3704 role-based access control to be used to restrict which entities 3705 can author a given policy. Note that Role is a type of 3706 SUPAPolicyMetadata. 3708 5.14.1. SUPAPolicySource Attributes 3710 Currently, no attributes are defined for this class. 3712 5.14.2. SUPAPolicySource Relationships 3714 SUPAPolicySource participates in a single relationship, 3715 SUPAHasPolicySource, as defined in section 5.3.2.1. 3716 SUPAPolicySource, and its subclasses, inherit the 3717 SUPAHasDecoratedPolicyComponent aggregation, which was 3718 defined in section 5.7.3. 3720 5.15. The Concrete Class "SUPAPolicyTarget" 3722 This is an optional class that defines a set of managed entities 3723 that a SUPAPolicy is applied to. Figure 12 shows a class diagram 3724 of the SUPAPolicyTarget. 3726 A managed object must satisfy two conditions in order to be defined 3727 as a SUPAPolicyTarget. First, the set of managed entities that are 3728 to be affected by the SUPAPolicy must all agree to play the role of 3729 a SUPAPolicyTarget. In general, a managed entity may or may not be 3730 in a state that enables SUPAPolicies to be applied to it to change 3731 its state; hence, a negotiation process may need to occur to enable 3732 the SUPAPolicyTarget to signal when it is willing to have 3733 SUPAPolicies applied to it. Second, a SUPAPolicyTarget must be able 3734 to process (directly or with the aid of a proxy) SUPAPolicies. 3736 If a proposed SUPAPolicyTarget meets both of these conditions, it 3737 SHOULD set its supaPolicyTargetEnabled Boolean attribute to a 3738 value of TRUE. 3740 A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the 3741 role-object pattern). This enables role-based access control to 3742 be used to restrict which entities can author a given policy. 3743 Note that Role is a type of SUPAPolicyMetadata. 3745 5.15.1. SUPAPolicyTarget Attributes 3747 Currently, no attributes are defined for the SUPAPolicyTarget 3748 class. 3750 5.15.2. SUPAPolicyTarget Relationships 3752 SUPAPolicyTarget participates in a single relationship, 3753 SUPAHasPolicyTarget, as defined in section 5.3.2.3. 3755 5.16. The Abstract Class "SUPAPolicyMetadata" 3757 Metadata is information that describes and/or prescribes 3758 characteristics and behavior of another object that is **not** 3759 an inherent, distinguishing characteristic or behavior of that 3760 object (otherwise, it would be an integral part of that object). 3762 For example, a socialSecurityNumber attribute should not be part 3763 of a generic Person class. First, most countries in the world do 3764 not know what a social security number is, much less use them. 3765 Second, a person is not created with a social security number; 3766 rather, a social security number is used to track people for 3767 administering social benefits, though it is also used as a form 3768 of identification. 3770 Continuing the example, a better way to add this capability to a 3771 model would be to have a generic Identification class, then 3772 define a SocialSecurityNumber subclass, populate it as necessary, 3773 and then define a composition between a Person and it (this is a 3774 composition because social security numbers are not reused). 3776 Since social security numbers are given to US citizens, permanent 3777 residents, and temporary working residents, and because it is 3778 also used to administer benefits, the composition is realized 3779 as an association class to define how it is being used. 3781 An example of descriptive metadata for network elements would be 3782 documentation about best current usage practices (this could also 3783 be in the form of a reference). An example of prescriptive 3784 metadata for network elements would be the definition of a time 3785 period during which specific types of operations are allowable. 3787 This is an optional class that defines the top of a hierarchy of 3788 model elements that are used to define different types of metadata 3789 that can be applied to policy and policy component objects. This 3790 enables common metadata to be defined as objects and then reused 3791 when the metadata are applicable. One way to control whether 3792 SUPAPolicyMetadata objects are reused is by using the attributes 3793 of the SUPAHasPolicyMetadataDetail association class. 3795 It is recommended that this class, along with its 3796 SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator 3797 subclasses, be used as part of a conformant implementation. It is 3798 defined to be optional, since metadata is not strictly required. 3799 However, metadata can help specify and describe SUPAPolicyObject 3800 entities, and can also be used to drive dynamic behavior. 3802 5.16.1. SUPAPolicyMetadata Attributes 3804 This section defines the attributes of the SUPAPolicyMetadata 3805 class. 3807 5.16.1.1. The Attribute "supaPolMetadataDescription" 3809 This is an optional string attribute that defines a free-form 3810 textual description of this metadata object. 3812 5.16.1.2. The Attribute "supaPolMetadataIDContent" 3814 This is a mandatory string attribute that represents part of the 3815 object identifier of an instance of this class. It defines the 3816 content of the object identifier. It works with another class 3817 attribute, called supaPolMetadataIDEncoding, which defines how to 3818 interpret this attribute. These two attributes form a tuple, 3819 and together enable a machine to understand the syntax and value 3820 of an object identifier for the object instance of this class. 3822 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" 3824 This is an optional non-zero enumerated integer attribute that 3825 represents part of the object identifier of an instance of this 3826 class. It defines the format of the object identifier. It works 3827 with another class attribute, called supaPolMetadataIDContent, 3828 which defines the content of the object ID. 3830 These two attributes form a tuple, and together enable a machine 3831 to understand the syntax and value of an object identifier for 3832 the object instance of this class. The supaPolMetadataIDEncoding 3833 attribute is mapped to the following values: 3835 0: undefined 3836 1: GUID 3837 2: UUID 3838 3: URI 3839 4: FQDN 3841 5.16.1.4. The Attribute "supaPolMetadataName" 3843 This is an optional string attribute that defines the name of this 3844 SUPAPolicyMetadata object. 3846 5.16.2. SUPAPolicyMetadata Relationships 3848 SUPAPolicyMetadata participates in a single aggregation, which is 3849 defined in the following subsections. 3851 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" 3853 This is an optional aggregation that defines the set of 3854 SUPAPolicyMetadata that are aggregated by this particular 3855 SUPAPolicyObject. It is recommended that this aggregation be used 3856 as part of a conformant implementation. 3858 The multiplicity of this relationship is defined as 0..n on the 3859 aggregate (SUPAPolicyObject) side, and 0..n on the part 3860 (SUPAPolicyMetadata) side. This means that this relationship is 3861 optional. The semantics of this aggregation are implemented using 3862 the SUPAHasPolicyMetadataDetail association class. 3864 5.16.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail" 3866 This is an optional abstract association class, and defines the 3867 semantics of the SUPAHasPolicyMetadata aggregation. Its purpose is 3868 to determine which SUPAPolicyMetadata object instances should be 3869 attached to which particular object instances of the 3870 SUPAPolicyObject class. This is done by using the attributes and 3871 relationships of the SUPAPolicyMetadataDetail class to constrain 3872 which SUPAPolicyMetadata objects can be aggregated by which 3873 particular SUPAPolicyObject instances. It is recommended that this 3874 association class be used as part of a conformant implementation. 3876 5.16.2.2.1. The Attribute "supaPolMetadataIsApplicable" 3878 This is an optional Boolean attribute. If the value of this 3879 attribute is TRUE, then the SUPAPolicyMetadata object(s) of this 3880 particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated 3881 by this particular SUPAPolicyObject. 3883 5.16.2.2.2. The Attribute "supaPolMetadataConstraintEncoding" 3885 This is an optional non-negative enumerated integer that defines 3886 how to interpret each string in the supaPolMetadataConstraint 3887 class attribute. Values include: 3889 0: undefined 3890 1: OCL 2.4 3891 2: OCL 2.x 3892 3: OCL 1.x 3893 4: QVT 1.2 - Relations Language 3894 5: QVT 1.2 - Operational language 3895 6: Alloy 3897 Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the 3898 latest version as of this writing). QVT defines a set of languages 3899 (the two most powerful and useful are defined by enumerations 4 3900 and 5). Alloy is a language for describing constraints, and uses a 3901 SAT solver to guarantee correctness. 3903 If this class is instantiated, then this attribute SHOULD also be 3904 instantiated, and should be part of a conformant implementation. 3906 5.16.2.2.3. The Attribute "supaPolMetadataConstraint[0..n]" 3908 This is an optional array of string attributes. Each attribute 3909 specifies a constraint to be applied using the format identified 3910 by the value of the supaPolMetadataPolicyConstraintEncoding class 3911 attribute. This provides a more rigorous and flexible treatment of 3912 constraints than is possible in [RFC3460]. 3914 If this class is instantiated, then this attribute SHOULD also be 3915 instantiated, and should be part of a conformant implementation. 3917 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" 3919 This is an optional concrete class. It defines an object that will 3920 be wrapped by concrete instances of the SUPAPolicyMetadataDecorator 3921 class. It can be viewed as a "carrier" for metadata that will be 3922 attached to a subclass of SUPAPolicyObject. Since the decorator 3923 pattern is used, any number of concrete subclasses of the 3924 SUPAPolicyMetadataDecorator class can wrap an instance of the 3925 SUPAPolicyConcreteMetadata class. 3927 It is recommended that this class be used as part of a conformant 3928 implementation. 3930 5.17.1. SUPAPolicyConcreteMetadata Attributes 3932 Currently, two attributes are defined for the 3933 SUPAPolicyConcreteMetadata class, and are described in the 3934 following subsections. 3936 5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" 3938 This is an optional attribute. Its data type should be able to 3939 express a date and a time. This attribute defines the ending 3940 date and time that this Metadata object is valid for. 3942 5.17.1.2. The Attribute "supaPolMDValidPeriodStart" 3944 This is an optional attribute. Its data type should be able to 3945 express a date and a time. This attribute defines the starting 3946 date and time that this Metadata object is valid for. 3948 5.17.2. SUPAPolicyConcreteMetadata Relationships 3950 This class inherits the relationships of the SUPAPolicyMetadata 3951 class; see section 5.16.2. It can also be used by subclasses of 3952 the SUPAPolicyMetadataDecorator class, and hence, can participate 3953 in the HasSUPAMetadataDecorator aggregation; see section 5.18.2. 3955 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" 3957 This is an optional class, and is used to implement the decorator 3958 pattern (see section 5.7.1.) for metadata objects. This pattern 3959 enables all or part of one or more SUPAPolicyMetadataDecorator 3960 subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance. 3962 It is recommended that this class be used as part of a conformant 3963 implementation. 3965 5.18.1. SUPAPolicyMetadataDecorator Attributes 3967 Currently, no attributes are defined for the 3968 SUPAPolicyMetadataDecorator class. 3970 5.18.2. SUPAPolicyMetadataDecorator Relationships 3972 This class inherits the relationships of the SUPAPolicyMetadata 3973 class; see section 5.16.2. It also defines a single aggregation, 3974 HasSUPAMetadataDecorator, which is used to implement the decorator 3975 pattern, as described in the following subsections. 3977 5.18.2.1. The Aggregation "HasSUPAMetadataDecorator" 3979 This is an optional aggregation, and is part of a decorator 3980 pattern. It is used to enable a concrete instance of a 3981 SUPAPolicyMetadataDecorator to dynamically add behavior to a 3982 SUPAPolicyConcreteMetadata object instance. The semantics of this 3983 aggregation are defined by the HasSUPAMetadataDecoratorDetail 3984 association class. 3986 It is recommended that this aggregation be part of a conformant 3987 implementation. 3989 The multiplicity of this aggregation is 0..1 on the aggregate 3990 (SUPAPolicyMetadataDecorator) side and 1..n on the part 3991 (SUPAPolicyMetadata) side. This means that if this aggregation is 3992 defined, then at least one SUPAPolicyMetadata object (e.g., a 3993 concrete subclass of SUPAPolicyMetadataDecorator) must also be 3994 instantiated and wrapped by this SUPAPolicyConcreteMetadata object 3995 instance. The semantics of this aggregation are defined by the 3996 HasSUPAMetadataDecoratorDetail association class. 3998 5.18.2.2. The Association Class "HasSUPAMetadataDecoratorDetail" 4000 This is an optional concrete association class, and defines the 4001 semantics of the HasSUPAMetadataDecorator aggregation. The purpose 4002 of this class is to use the Decorator pattern to determine 4003 which SUPAPolicyMetadataDecorator object instances, if any, are 4004 required to augment the functionality of the 4005 SUPAPolicyConcreteMetadata object instance that is being used. 4007 It is recommended that this association class be part of a 4008 conformant implementation. 4010 Attributes for this association class will be defined in a future 4011 version of this document. 4013 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" 4015 This is an optional concrete class that defines access control 4016 information, in the form of metadata, that can be added to a 4017 SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata 4018 aggregation (see section 5.2.2.). This enables all or part of a 4019 standardized description and/or specification of access control 4020 for a given SUPAPolicyObject to be easily changed at runtime by 4021 wrapping an object instance of the SUPAPolicyConcreteMetadata 4022 class (or its subclass) with all or part of this object, and then 4023 adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata 4024 object instance. 4026 5.19.1. SUPAPolicyAccessMetadataDef Attributes 4028 Currently, the SUPAPolicyAccessMetadataDef class defines three 4029 attributes; these are described in the following subsections. 4031 5.19.1.1. The Attribute "supaPolAccessPrivilegeDef" 4033 This is an optional non-negative enumerated integer attribute. It 4034 specifies the access privileges that external Applications have 4035 when interacting with a specific SUPAPolicyObject that is adorned 4036 with an instance of this SUPAPolicyAccessMetadataDef object. This 4037 enables the management system to control, in a consistent manner, 4038 the set of operations that external Applications have for 4039 SUPAPolicies and components of SUPAPolicies. Values include: 4041 0: undefined 4042 1: access only (for all policy components) 4043 2: access and update (for all policy components) 4044 3: privileges are specified by an external MAC model 4045 4: privileges are specified by an external DAC model 4046 5: privileges are specified by an external RBAC model 4047 6: privileges are specified by an external ABAC model 4048 7: privileges are specified by an external custom model 4050 Values 1 and 2 apply to ALL SUPAPolicyObject instances that are 4051 adorned with this SUPAPolicyConcreteMetadata object instance; 4052 these two settings are "all-or-nothing" settings, and are included 4053 for ease of use. 4055 Values 3-7 indicate that a formal external access control model is 4056 used. The name of this model, and its location, are specified in 4057 two other class attributes, called supaPolAccessPrivilegeModelName 4058 and supaPolAccessPrivilegeModelRef. MAC, DAC, RBAC, and ABAC 4059 (values 3-6 stand for Mandatory Access Control, Discretionary 4060 Access Control, Role-Based Access Control, and Attribute-Based 4061 Access Control, respectively. A value of 7 indicates that a formal 4062 external model that is not MAC, DAC, RBAC, or ABAC is used. 4064 5.19.1.2. The Attribute "supaPolAccessPrivilegeModelName" 4066 This is an optional string attribute that contains the name of 4067 the access control model being used. If the value of the 4068 supaPolAccessPrivilegeDef is 0-2, then the value of this attribute 4069 is not applicable. Otherwise, the text in this class attribute 4070 should be interpreted according to the value of the 4071 supaPolAccessPrivilegeModelRef class attribute. 4073 5.19.1.3. The Attribute "supaPolAccessPrivilegeModelRef" 4075 This is an optional non-negative enumerated integer attribute 4076 that defines the data type of the supaPolAccessPrivilegeModelName 4077 attribute. If the value of the supaPolAccessPrivilegeDef class 4078 attribute is 0-2, then the value of this attribute is not 4079 applicable. Otherwise, the value of this class attribute defines 4080 how to interpret the text in the supaPolAccessPrivilegeModelRef 4081 class attribute. Values include: 4083 0: Undefined 4084 1: URI 4085 2: GUID 4086 3: UUID 4087 4: FQDN 4089 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" 4091 This is an optional concrete class that defines versioning 4092 information, in the form of metadata, that can be added to a 4093 SUPAPolicyObject. This enables all or part of a standardized 4094 description and/or specification of version information for a 4095 given SUPAPolicyObject to be easily changed at runtime by 4096 wrapping an object instance of the SUPAPolicyConcreteMetadata 4097 class (or its subclass) with all or part of this object. 4099 5.20.1. SUPAPolicyVersionMetadataDef Attributes 4101 Version information is defined in a generic format as follows: 4103 ... 4105 In this approach: 4107 o supaVersionMajor denotes a major new release 4108 o supaVersionMinor denotes an incremental release, that adds new 4109 features and/or bug fixes to a major release 4110 o supaVersionRelType denotes the type of release (e.g., internal, 4111 alpha, production) 4112 o supaVersionRelTypeNum denotes an incremental release of ability 4113 particular type 4115 Currently, the SUPAPolicyVersionMetadataDef class defines three 4116 attributes; these are described in the following subsections. 4118 5.20.1.1. The Attribute "supaVersionMajor" 4120 This is an optional string attribute, and contains a string 4121 (typically representing an integer) indicating a significant 4122 increase in functionality is present in this version. 4124 5.20.1.2. The Attribute "supaVersionMinor" 4126 This is an optional string attribute, and contains a string 4127 (typically representing an integer) indicating that this release 4128 contains a set of features and/or bug fixes that collectively do 4129 not warrant incrementing the supaVersionMajor attribute. This 4130 attribute should only be used if the supaVersionMajor attribute 4131 is NOT NULL. 4133 5.20.1.3. The Attribute "supaVersionRelTypeNum" 4135 This is an optional integer attribute, and contains a string 4136 defining the type of release of this SUPAPolicyObject. Values 4137 include: 4139 0: undefined 4140 1: internal 4141 2: alpha 4142 3: beta 4143 4: release candidate 4144 5: production 4145 6: maintenance 4147 This attribute should only be used if the supaVersionMinor 4148 attribute is NOT NULL. 4150 5.20.1.4. The Attribute "supaVersionRelTypeNum" 4152 This is an optional string attribute, and contains a string 4153 defining the incremental release associated with the 4154 supaVersionRelType class attribute. This attribute should only be 4155 used if the supaVersionRelType attribute is NOT NULL. 4157 6. SUPA ECAPolicyRule Information Model 4159 This section defines the classes, attributes, and relationships 4160 of the SUPA ECAPolicyRule Information Model (EPRIM). Unless 4161 otherwise stated, all classes (and attributes) defined in this 4162 section were abstracted from DEN-ng [2], and a version of them are 4163 in the process of being added to [5]. 4165 6.1. Overview 4167 Conceptually, the EPRIM is a set of subclasses that specialize the 4168 concepts defined in the GPIM for representing the components of a 4169 Policy that uses ECA semantics. This is shown in Figure 23 (only 4170 new EPRIM subclasses and their GPIM superclasses are shown). 4172 (Class of another model that SUPA is integrating into) 4173 | 4174 +---SUPAPolicyObject (5.2) 4175 | 4176 +---SUPAPolicyStructure (5.3) 4177 | | 4178 | +---SUPAECAPolicyRule (6.4) 4179 | | 4180 | +---SUPAECAPolicyRuleAtomic (6.5) 4181 | | 4182 | +---SUPAECAPolicyRuleComposite (6.6) 4183 | 4184 +---SUPAPolicyComponentStructure (5.6) 4185 | 4186 +---SUPAPolicyClause (5.7) 4187 | | 4188 | +---SUPABooleanClause (6.7) 4189 | | 4190 | +---SUPAECAPolicyRuleAtomic (6.8) 4191 | | 4192 | +---SUPAECAPolicyRuleComposite (6.9) 4193 | 4194 +---SUPAPolicyComponentDecorator (5.9) 4195 | 4196 +---SUPAECAComponent(6.10) 4197 | | 4198 | +---SUPAPolicyEvent (6.11) 4199 | | 4200 | +---SUPAPolicyCondition (6.12) 4201 | | 4202 | +---SUPAPolicyAction (6.13) 4204 Figure 23. The EPRIM Class Hierarchy 4206 Specifically, the EPRIM specializes the SUPAPolicyStructure class 4207 class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it 4208 also specializes two subclasses of the SUPAPolicyComponentStructure 4209 class to create two new sets of policy components. These two 4210 SUPAPolicyComponentStructure subclasses are: 4212 o a new subclass of SUPAPolicyClause, called SUPABooleanClause 4213 (see sections 6.7 - 6.9), is defined for constructing Boolean 4214 clauses that are specific to the needs of ECA Policy Rules 4215 o a new subclass of SUPAPolicyComponentDecorator, called 4216 SUPAECAComponent (see sections 6.10 - 6.13), is defined for 4217 constructing reusable objects that represent Events, 4218 Conditions, and Actions 4220 The EPRIM provides new functionality, based on the GPIM, by 4221 extending the GPIM to define new classes and relationships. The 4222 EPRIM does NOT define new classes that are not inherited from 4223 existing GPIM classes. This ensures that the semantics of the GPIM 4224 are not changed, even though new functionality (for ECA Policy 4225 Rules and components) are being defined. 4227 The overall strategy for refining the GPIM is as follows: 4229 o SUPAECAPolicyRule is defined as a subclass of the GPIM 4230 SUPAPolicyStructure class 4231 o A SUPAECAPolicyRule has event, condition, and action clauses 4232 o Conceptually, this can be viewed as three aggregations 4233 between the SUPAECAPolicyRule and each clause 4234 o Each aggregation uses an instance of a concrete subclass of 4235 SUPAPolicyClause; this can be a SUPABooleanClause 4236 (making it ECA-specific), a SUPAEncodedClause (making it 4237 generic in nature), or a new subclass of SUPAPolicyClause 4238 o Concrete subclasses of SUPAPolicyClause may be decorated 4239 with zero or more concrete subclasses of the 4240 SUPAPolicyComponentDecorator class 4241 o An optional set of GPIM SUPAPolicySource objects can be 4242 defined to represent the authoring of a SUPAECAPolicyRule 4243 o An optional set of GPIM SUPAPolicyTarget objects can be 4244 defined to represent the set of managed entities that will be 4245 affected by this SUPAECAPolicyRule 4246 o An optional set of SUPAPolicyMetadata can be defined for any 4247 of the objects that make up a SUPAECAPolicyRule, including 4248 any of its components 4250 6.2. Constructing a SUPAECAPolicyRule 4252 There are several different ways to construct a SUPAECAPolicyRule; 4253 they differ in which set of components are used to define the 4254 content of the SUPAECAPolicyRule, and whether each component is 4255 decorated or not. The following are some examples of creating a 4256 SUPAECAPolicyRule: 4258 o Define three types of SUPABooleanClauses, one each for the 4259 event, condition, and action clauses that make up a 4260 SUPAECAPolicyRule 4261 o For one or more of the above clauses, associate an 4262 appropriate set of SUPAPolicyEvent, SUPAPolicyCondition, or 4263 SUPAPolicyAction objects, and complete the clause using an 4264 appropriate SUPAPolicyOperator and a corresponding 4265 SUPAPolicyValue or SUPAPolicyVariable 4266 o Note that compound Boolean clauses may be formed using 4267 one or more SUPABooleanClauseComposite objects with one or 4268 more SUPABooleanClauseAtomic objects 4269 o Define a SUPAPolicyCollection component, which is used to 4270 aggregate a set of objects appropriate for a clause, and 4271 complete the clause using an appropriate SUPAPolicyOperator 4272 and a corresponding SUPAPolicyValue or SUPAPolicyVariable 4273 o Create a new concrete subclass of SUPAPolicyComponentStructure 4274 (i.e., a sibling class of SUPAPolicyComponentDecorator and 4275 SUPAPolicyClause), and use this new subclass in a concrete 4276 subclass of SUPABooleanClause; note that this approach enables 4277 the new concrete subclass of SUPAPolicyComponentStructure to 4278 optionally be decorated as well 4279 o Create a new subclass of SUPAPolicyComponentDecorator (e.g., 4280 a sibling of SUPAECAComponent) that provides ECA-specific 4281 functionality, and use that to decorate a SUPAPolicyClause 4282 o Create a new concrete subclass of SUPAPolicyStructure that 4283 provides ECA-specific functionality, and define all or part 4284 of its content by aggregating a set of SUPAPolicyClauses 4286 6.3. Working With SUPAECAPolicyRules 4288 A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that 4289 MUST have three clauses, defined as follows: 4291 o The event clause defines a Boolean expression that, if TRUE, 4292 triggers the evaluation of its condition clause (if the 4293 event clause is not TRUE, then no further action for this 4294 policy rule takes place). 4295 o The condition clause defines a Boolean expression that, if 4296 TRUE, enables the actions in the action clause to be executed 4297 (if the condition clause is not TRUE, then no further action 4298 for this policy rule takes place). 4299 o The action clause contains a set of actions (note that an 4300 action MAY invoke another SUPAECAPolicyRule; see section 4301 6.13). 4303 Each of the above clauses can be a simple Boolean expression (of 4304 the form {variable operator value}, or a compound Boolean 4305 expression consisting of Boolean combinations of clauses. 4306 Compound Boolean expressions SHOULD be in CNF or DNF. 4308 Note that each of the above three clauses MAY have a set of 4309 SUPAPolicyMetadata objects that can constrain, or otherwise 4310 affect, how that clause is treated. For example, a set of 4311 SUPAPolicyMetadata MAY affect whether none, some, or all actions 4312 are executed, and what happens if an action fails. 4314 Each of the three clauses can be constructed from either a 4315 SUPAEncodedClause or a SUPABooleanClause. The advantage of using 4316 SUPAEncodedClauses is simplicity, as the content of the clause is 4317 encoded directly into the attributes of the SUPAEncodedClause. The 4318 advantage of using SUPABooleanClauses is reusability, since each 4319 term in each clause is potentially a reusable object. 4321 Since a SUPABooleanClause is a subclass of a SUPAPolicyClause 4322 (see Section 6.7), it can be decorated by one or more concrete 4323 subclasses of SUPAPolicyComponentDecorator. Therefore, a 4324 SUPAECAPolicyRule can be built entirely from objects defined in 4325 the GPIM and EPRIM, which facilitates the construction of 4326 SUPAPolicies by a machine. 4328 The relation between a SUPAECAPolicyRule and a SUPAPolicyClause 4329 is shown in Figure 24, and is explained in further detail in 4330 Section 6.4. 4332 SUPAHasPolicyClause 4333 +----------------+------------------------+ 4334 | ^ | 4335 | | | 4336 / \ | | 4337 A | | 4338 A \ / 0..1 | A 1..n \ / 4339 +----------+-----------+ | +-----------+------+ 4340 | SUPAPolicyStructure | | | SUPAPolicyClause | 4341 +----------+-----------+ | +-----------+------+ 4342 / \ | / \ 4343 I A | | 4344 I +----------+----------------+ | 4345 I | SUPAHasPolicyClauseDetail | | 4346 I +---------------------------+ | 4347 I | 4348 C I A | 4349 +----------+----------+ +--------+----------+ 4350 | SUPAECAPolicyRule | | SUPABooleanClause | 4351 +---------------------+ +-------------------+ 4353 Figure 24. SUPAECAPolicyRule Clauses 4355 The SUPAHasPolicyClause aggregation is implemented using the 4356 SUPAHasPolicyClauseDetail association class. These were 4357 described in sections 5.4.2.1 and 5.4.2.2, respectively. 4359 6.4. The Abstract Class "SUPAECAPolicyRule" 4361 This is a mandatory abstract class, which is a PolicyContainer 4362 that aggregates PolicyEvents, PolicyConditions, PolicyActions into 4363 a type of policy rule known as an Event-Condition-Action (ECA) 4364 policy rule. As previously explained, this has the following 4365 semantics: 4367 IF the event clause evaluates to TRUE 4368 IF the condition clause evaluates to TRUE 4369 THEN execute actions in the action clause 4370 ENDIF 4371 ENDIF 4373 The event clause, condition clause, and action clause collectively 4374 form a three-tuple. Each clause MUST be defined by at least one 4375 SUPAPolicyClause (which MAY be decorated with other elements, 4376 as described in section 5.7). 4378 Each of the three types of clauses is a 3-tuple of the form: 4380 {variable operator value} 4382 Each of the three clauses MAY be combined with additional clauses 4383 using any combination of logical AND, OR, and NOT operators; this 4384 forms a "compound" Boolean clause. For example, if A, B, and C are 4385 three attributes in an event, then a valid event clause could be: 4387 (A AND B) OR C 4389 Note that the above expression is in DNF; the equivalent CNF form 4390 is ((A OR C) AND (B OR C)). In either case, the output of all 4391 three clauses is either TRUE or FALSE; this facilitates combining 4392 and chaining SUPAECAPolicyRules. 4394 An action clause MAY invoke a new SUPAECAPolicyRule; see section 4395 6.13 for more details. 4397 An ECAPolicyRule MAY be optionally augmented with PolicySources 4398 and/or PolicyTargets (see sections 5.16 and 5.17, respectively). 4399 In addition, all objects that make up a SUPAECAPolicyRule MAY 4400 have SUPAPolicyMetadata (see section 5.16) attached to them to 4401 further describe and/or specify behavior. 4403 When defined in an information model, each of the event, condition, 4404 and action clauses MUST be represented as an aggregation between a 4405 SUPAECAPolicyRule (the aggregate) and a set of event, condition, 4406 or action objects (the components). However, a data model MAY map 4407 these definitions to a more efficient form (e.g., by flattening 4408 these three types of object instances, along with their respective 4409 aggregations, into a single object instance). 4411 The composite pattern [3] is applied to the SUPAECAPolicyRule 4412 class, enabling its (concrete) subclasses to be used as either a 4413 stand-alone policy rule or as a hierarchy of policy rules. This is 4414 shown in Figure 25. 4416 A 4417 1..n +-------------------+ 4418 \| | 4419 +--------------- + SUPAECAPolicyRule | 4420 | /| | 4421 | +--------+----------+ 4422 | / \ 4423 | SUPAHasECAPolicyRule I 4424 | I 4425 | I 4426 | I 4427 | +---------------+-------------+ 4428 | I I 4429 / \ I I 4430 A I I 4431 C \ / 0..1 I C I 4432 +-----+---------+----------+ +-----------+-----------+ 4433 |SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic| 4434 +--------------------------+ +-----------------------+ 4436 Figure 25. The Composite Pattern Applied to a SUPAECAPolicyRule 4438 SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both 4439 inherit from SUPAECAPolicyRule. This means that they are both 4440 a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule 4441 aggregation enables a particular SUPAECAPolicyRuleComposite 4442 object to aggregate both SUPAECAPolicyRuleComposite as well as 4443 SUPAECAPolicyRuleAtomic objects. In contrast, a 4444 SUPAECAPolicyRuleAtomic can NOT aggregate either a 4445 SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. 4446 SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are 4447 defined in sections 6.5 and 6.6, respectively. 4449 Note that the HasSUPAECAPolicyRule aggregation is defined by the 4450 HasSUPAECAPolicyRuleDetail association class; both are defined 4451 in sections 6.6.2 and 6.6.3, respectively. 4453 6.4.1. SUPAECAPolicyRule Attributes 4455 Currently, the SUPAECAPolicyRule defines two attributes, as 4456 described in the following subsections. 4458 6.4.1.1. The Attribute "supaECAPolicyRulePriority" 4460 This is a mandatory non-negative integer attribute that defines 4461 the priority of this particular SUPAECAPolicyRule. A larger value 4462 indicates a higher priority. A default value of 0 MAY be assigned. 4464 Priority is used primarily for 2 reasons: (1) to resolve conflicts 4465 among policy actions (e.g., given a set of conflicting actions, 4466 which one will execute) and (2) to define the execution order of 4467 policy actions (e.g., when one action may depend on the output of 4468 one or more previous actions). 4470 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" 4472 This is an optional non-negative enumerated integer whose value 4473 defines the current status of this policy rule. Values include: 4475 0: In development, not ready to be deployed 4476 1: Ready to be deployed 4477 2: Deployed but not enabled 4478 3: Deployed and enabled, but not executed 4479 4: Executed without errors 4480 5: Executed with errors 4481 6: Aborted during execution 4483 6.4.2. SUPAECAPolicyRule Relationships 4485 Currently, the SUPAECAPolicyRule does not define any 4486 relationships. It inherits all four relationships defined by 4487 the SUPAPolicyStructure class (see section 5.3.2.). 4489 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" 4491 This is a mandatory concrete class. This class is a type of 4492 PolicyContainer, and represents a SUPAECAPolicyRule that can 4493 operate as a single, stand-alone, manageable object. Put another 4494 way, a SUPAECAPolicyRuleAtomic object can NOT be modeled as a set 4495 of hierarchical SUPAECAPolicyRule objects; if this is required, 4496 then a SUPAECAPolicyRuleComposite object should be used instead. 4498 6.5.1. SUPAECAPolicyRuleAtomic Attributes 4500 Currently, the SUPAECAPolicyRuleAtomic class does not define any 4501 attributes. 4503 6.5.2. SUPAECAPolicyRuleAtomic Relationships 4505 Currently, the SUPAECAPolicyRuleAtomic class does not define any 4506 relationships. It inherits all four relationships defined by the 4507 SUPAPolicyStructure class (see section 5.3.2.). 4509 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" 4511 This is a mandatory concrete class. This class is a type of 4512 PolicyContainer, and represents a SUPAECAPolicyRule as a hierarchy 4513 of SUPAPolicy objects, where the hierarchy contains instances of a 4514 SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects. 4515 Each of the SUPAPolicy objects, including the outermost 4516 SUPAECAPolicyRuleComposite object, are separately manageable. More 4517 importantly, each SUPAECAPolicyRuleComposite object represents an 4518 aggregated object that is itself manageable. 4520 6.6.1. SUPAECAPolicyRuleComposite Attributes 4522 Currently, the SUPAECAPolicyRuleComposite defines one attribute, 4523 as described in the following subsection. 4525 6.6.1.1. The Attribute "supaECAEvalStrategy" 4527 This is a mandatory, non-zero, integer attribute that enumerates 4528 a set of allowable alternatives that define how the set of 4529 SUPAECAPolicyRule object instances in a SUPAECAPolicyRuleComposite 4530 object are evaluated. It is assumed that the event and condition 4531 clauses of the SUPAECAPolicyRules have evaluated to TRUE (e.g., the 4532 event has occurred and the conditions were met). Values include: 4534 0: undefined 4535 1: execute the first SUPAECAPolicyRule in the 4536 SUPAECAPolicyRuleComposite and then terminate 4537 2: execute only the highest priority SUPAECAPolicyRule(s) in 4538 the SUPAECAPolicyRuleComposite and then terminate 4539 3: execute all SUPAECAPolicyRules in prioritized order (if 4540 any) regardless of whether their SUPAPolicyActions 4541 succeed or fail 4542 4: execute all SUPAECAPolicyRules in prioritized order (if 4543 any) until at least one SUPAPolicyAction in a 4544 SUPAECAPolicyRule fails, and then terminate 4546 If the value of supaECAEvalStrategy is 3 or 4, then all 4547 SUPAECAPolicyRules that have a priority will be executed first 4548 (starting with the SUPAECAPolicyRule(s) that have the highest 4549 priority, and descending); all SUPAECAPolicyRule(s) that do not 4550 have a priority are then executed (in any order). 4552 Assume that the actions in a given SUPAECAPolicyRuleComposite 4553 are defined as follows 4555 SUPAECAPolicyRule A, priority 0 4556 SUPAECAPolicyRule B, priority 10 4557 SUPAECAPolicyRule C, priority 5 4558 SUPAECAPolicyRule D, priority 10 4559 SUPAECAPolicyRule E, priority 2 4561 Then, if the supaECAEvalStrategy attribute value equals: 4563 0: an error is issued 4564 1: only SUPAECAPolicyRule A is executed 4565 2: only SUPAECAPolicyRules B and D are executed 4566 3: all SUPAECAPolicyRules are executed, regardless of any 4567 failures in their SUPAPolicyActions 4568 4: all SUPAECAPolicyRules are executed until a failure is 4569 detected, and then execution for all SUPAECAPolicyRules 4570 terminate 4572 6.6.2. SUPAECAPolicyRuleComposite Relationships 4574 Currently, the SUPAECAPolicyRuleComposite defines a single 4575 aggregation between it and SUPAECAPolicyRule, as described below. 4577 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" 4579 This is an optional aggregation that implements the composite 4580 pattern. The multiplicity of this aggregation is 0..1 on the 4581 aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part 4582 (SUPAECAPolicyRule) side. This means that if this aggregation 4583 is defined, then at least one SUPAECAPolicyRule object (which may 4584 be either an instance of a SUPAECAPolicyRuleAtomic or a 4585 SUPAECAPolicyRuleComposite class) must also be instantiated and 4586 aggregated by this particular SUPAECAPolicyRuleComposite object. 4587 The semantics of this aggregation are defined by the 4588 SUPAHasECAPolicyRuleDetail association class. 4590 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" 4592 This is an optional association class, and defines the semantics 4593 of the SUPHasECAPolicyRule aggregation. This enables the 4594 attributes and relationships of the SUPAHasECAPolicyRuleDetail 4595 class to be used to constrain which SUPHasECAPolicyRule objects 4596 can be aggregated by this particular SUPAECAPolicyRuleComposite 4597 object instance. 4599 6.6.3.1. The Attribute "supaECAPolicyIsDefault" 4601 This is an optional Boolean attribute. If the value of this 4602 attribute is true, then this SUPAECAPolicyRule is a default 4603 policy, and will be executed if no other SUPAECAPolicyRule 4604 in the SUPAECAPolicyRuleComposite container has been executed. 4605 This is a convenient way for error handling, though care should 4606 be taken to ensure that only one default policy rule is defined 4607 per SUPAECAPolicyRuleComposite container. 4609 6.7. The Abstract Class "SUPABooleanClause" 4611 A SUPABooleanClause specializes a SUPAPolicyClause, and defines 4612 a Boolean expression consisting of a standard structure in the 4613 form of a SUPAPolicyVariable, a SUPAPolicyOperator, and a 4614 SUPAPolicyValue. For example, this enables the following Boolean 4615 clause to be defined: 4617 Foo >= Baz 4619 where 'Foo' is a PolicyVariable, '>=' is a PolicyOperator, and 4620 'Baz' is a PolicyValue. 4622 Note that in this approach, the SUPAPolicyVariable and 4623 SUPAPolicyValue terms are defined as an appropriate subclass of 4624 the SUPAPolicyComponentDecorator class; it is assumed that the 4625 SUPAPolicyOperator is an instance of the SUPAPolicyOperator class. 4626 This enables the EPRIM, in conjunction with the GPIM, to be used 4627 as a reusable class library. This encourages interoperability, 4628 since each element of the clause is itself an object defined by 4629 the SUPA object hierarchy. 4631 An entire SUPABooleanClause may be negated by setting the 4632 supaBoolClauseIsNegated class attribute of the SUPABooleanClause 4633 class to TRUE. Individual terms of a Boolean clause can be negated 4634 by using the supaTermIsNegated Boolean attribute in the 4635 SUPAPolicyTerm class (see section 5.10). 4637 A PolicyClause is in Conjunctive Normal Form (CNF) if it is a 4638 sequence of logically ANDed terms, where each term is a sequence 4639 of logically ORed terms. 4641 A PolicyClause is in Disjunctive Normal Form (DNF) if it is a 4642 sequence of logically ORed terms, where each term is a sequence 4643 of logically ANDed terms. 4645 The construction of more complex clauses, which consist of a set 4646 of simple clauses in CNF or DNF (as shown in the above example), 4647 is provided by using the composite pattern [3] to construct two 4648 concrete subclasses of the abstract SUPABooleanClause class. These 4649 are called SUPABooleanClauseAtomic and SUPABooleanClauseComposite, 4650 and are defined in sections 6.8 and 6.9, respectively. This 4651 enables instances of either a SUPABooleanClauseAtomic and/or a 4652 SUPABooleanClauseComposite to be aggregated into a 4653 SUPABooleanClauseComposite object. 4655 6.7.1. SUPABooleanClause Attributes 4657 The SUPABooleanClause class currently defines one attribute, 4658 which are defined in the following subsections. 4660 6.7.1.1. The Attribute "supaBoolClauseIsNegated" 4662 This is a mandatory Boolean attribute. If the value of this 4663 attribute is TRUE, then this (entire) SUPABooleanClause is 4664 negated. Note that the supaPolTermIsNegated class attribute of 4665 the SUPAPolicyTerm class is used to negate a single term. 4667 6.7.2. SUPABooleanClause Relationships 4669 Currently, no relationships are defined for the SUPABooleanClause 4670 class. It inherits the relationships of SUPAPolicyClause (see 4671 section 5.5.). 4673 6.8. The Concrete Class "SUPABooleanClauseAtomic" 4675 This is a mandatory concrete class that represents a 4676 SUPABooleanClause that can operate as a single, stand-alone, 4677 manageable object. A SUPABooleanClauseAtomic object can NOT be 4678 modeled as a set of hierarchical clauses; if this functionality is 4679 required, then a SUPABooleanClauseComposite object must be used. 4680 Examples of Boolean clauses that could be contained in a 4681 SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P 4682 and Q are literals (e.g., a variable name that can be either true 4683 or false, or a formula that evaluates to a literal). Examples of 4684 Boolean clauses that are NOT in CNF are NOT(P AND Q), 4685 (P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent 4686 forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and 4687 P AND (Q OR S) AND (Q OR S), respectively. 4689 6.8.1. SUPABooleanClauseAtomic Attributes 4691 No attributes are currently defined for the 4692 SUPABooleanClauseAtomic class. 4694 6.8.2. SUPABooleanClauseAtomic Relationships 4696 Currently, no relationships are defined for the 4697 SUPABooleanClauseAtomic class. It inherits the relationships of 4698 SUPAPolicyClause (see section 5.5.). 4700 6.9. The Concrete Class "SUPABooleanClauseComposite" 4702 This is a mandatory concrete class that represents a 4703 SUPABooleanClause that can operate as a hierarchy of PolicyClause 4704 objects, where the hierarchy contains instances of 4705 SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite 4706 objects. Each of the SUPABooleanClauseAtomic and 4707 SUPABooleanClauseComposite objects, including the outermost 4708 SUPABooleanClauseComposite object, are separately manageable. 4710 More importantly, each SUPAECAPolicyRuleComposite object 4711 represents an aggregated object that is itself manageable. 4712 Examples of Boolean clauses that could be contained in a 4713 SUPABooleanClauseAtomic include ((P OR Q) AND R), and 4714 ((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, and 4715 T are literals. 4717 6.9.1. SUPABooleanClauseComposite Attributes 4719 Two attributes are currently defined for the 4720 SUPABooleanClauseComposite class, and are described in the 4721 following subsections. 4723 6.9.1.1. The Attribute "supaBoolClauseBindValue" 4725 This is a mandatory non-zero integer attribute, and defines the 4726 order in which terms bind to a clause. For example, the Boolean 4727 expression "((A AND B) OR (C AND NOT (D OR E)))" has the following 4728 binding order: terms A and B have a bind value of 1; term C has a 4729 binding value of 2, and terms D and E have a binding value of 3. 4731 6.9.1.2. The Attribute "supaBoolClauseIsCNF" 4733 This is an optional Boolean attribute. If the value of this 4734 attribute is TRUE, then this SUPABooleanClauseComposite is in CNF 4735 form. Otherwise, it is in DNF form. 4737 6.9.2. SUPABooleanClauseComposite Relationships 4739 Currently, the SUPABooleanClauseComposite class defined a single 4740 aggregation, which is described in the subsections below. 4742 6.9.2.1. The Aggregation "SUPAHasBooleanClause" 4744 This is a mandatory aggregation that defines the set of 4745 SUPABooleanClause objects that are aggregated by this 4746 SUPABooleanClauseComposite object. 4748 The multiplicity of this relationship is 0..1 on the aggregate 4749 (SUPABooleanClauseComposite) side, and 1..n on the part 4750 (SUPABooleanClause) side. This means that one or more 4751 SUPABooleanClauses are aggregated and used to define this 4752 SUPABooleanClauseComposite object. The 0..1 cardinality on the 4753 SUPABooleanClauseComposite side is necessary to enable 4754 SUPABooleanClauses to exist (e.g., in a PolicyRepository) before 4755 they are used by a SUPABooleanClauseComposite. The semantics of 4756 this aggregation is defined by the SUPAHasBooleanClauseDetail 4757 association class. 4759 6.9.3. The Concrete Class "SUPAHasBooleanClauseDetail" 4761 This is a mandatory association class that defines the semantics 4762 of the SUPAHasBooleanClause aggregation. This enables the 4763 attributes and relationships of the SUPAHasBooleanClauseDetail 4764 class to be used to constrain which SUPABooleanClause objects 4765 can be aggregated by this particular SUPABooleanClauseComposite 4766 object instance. 4768 6.9.3.1. SUPAHasBooleanClauseDetail Attributes 4770 The SUPAHasBooleanClauseDetail class currently does not define 4771 any attributes at this time. 4773 6.10. The Abstract Class "SUPAECAComponent" 4775 This is a mandatory abstract class that defines three concrete 4776 subclasses, one each to represent the concepts of reusable events, 4777 conditions, and actions. They are called SUPAPolicyEvent, 4778 SUPAPolicyCondition, and SUPAPolicyAction, respectively. 4780 SUPAECAComponents provide two different ways to construct 4781 SUPAPolicyClauses. The first is for the SUPAECAComponent to be 4782 used as either a SUPAPolicyVariable or a SUPAPolicyValue, and the 4783 second is for the SUPAECAComponent to contain the entire clause 4784 text. 4786 For example, suppose it is desired to define a policy condition 4787 clause with the text 'queueDepth > 10'. The two approaches could 4788 satisfy this as follows: 4790 Approach #1 (canonical form): 4791 SUPAPolicyCondition.supaPolicyConditionData contains the text 4792 'queueDepth' 4793 SUPAPolicyOperator.supaPolOpType is set to '1' (greater than) 4794 SUPAPolicyValue.supaPolValContent is set to '10' 4796 Approach #2 (SUPAECAComponent represents the entire clause): 4797 SUPAPolicyCondition.supaPolicyConditionData contains the text 4798 'queueDepth > 10' 4800 The class attribute supaECACompIsTerm, defined in subsection 4801 6.10.1.1, is used to identify which of these two approaches is 4802 used by an object instance of this class. 4804 6.10.1. SUPAECAComponent Attributes 4806 A single attribute is currently defined for this class, and is 4807 described in the following subsection. 4809 6.10.1.1. The Attribute supaECACompIsTerm 4811 This is an optional Boolean attribute. If the value of this 4812 attribute is TRUE, then this SUPAECAComponent is used as the value 4813 of a SUPAPolicyTerm to construct a SUPAPolicyClause (this is 4814 approach #1 in section 6.10 above). If the value of this attribute 4815 is FALSE, then this SUPAECAComponent contains the text of the 4816 entire corresponding SUPAPolicyClause (this is approach #2 in 4817 section 6.10 above). 4819 6.10.2. SUPAECAComponent Relationships 4821 No relationships are currently defined for this class. 4823 6.11. The Concrete Class "SUPAPolicyEvent" 4825 This is a mandatory concrete class that represents the concept of 4826 an Event that is applicable to a policy management system. Such 4827 an Event is defined as any important occurrence in time of a 4828 change in the system being managed, and/or in the environment of 4829 the system being managed. SUPAPolicyEvents can be used as part of 4830 a SUPAPolicyClause; this is done by specifying the attribute name 4831 and value of an Event in the supaPolicyEventData attribute of the 4832 SUPAPolicyEvent. This enables event attributes to be used as part 4833 of a SUPAPolicyClause. 4835 Note: this class does NOT model the "raw" occurrences of Events. 4836 Rather, it represents the concept of an Event object whose class 4837 attributes describe pertinent attributes that can trigger the 4838 evaluation of a SUPAECAPolicyRule. 4840 6.11.1. SUPAPolicyEvent Attributes 4842 Currently, five attributes are defined for the SUPAPolicyEvent 4843 class, which are described in the following subsections. 4845 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 4847 This is an optional Boolean attribute. If the value of this 4848 attribute is TRUE, then this SUPAPolicyEvent has been pre- 4849 processed by an external entity, such as an Event Service Bus, 4850 before it was received by the Policy Management System. 4852 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" 4854 This is an optional Boolean attribute. If the value of this 4855 attribute is TRUE, then this SUPAPolicyEvent has been produced by 4856 the Policy Management System. If the value of this attribute is 4857 FALSE, then this SUPAPolicyEvent has been produced by an entity 4858 in the system being managed. 4860 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" 4862 This is a mandatory array of string attributes, and contains the 4863 subject that this PolicyEvent describes. 4865 6.11.1.4. The Attribute "supaPolicyEventEncoding" 4867 This is a mandatory non-zero enumerated integer attribute, and 4868 defines how to interpret the supaPolicyEventData class attribute. 4869 These two attributes form a tuple, and together enable a machine 4870 to understand the syntax and value of the data carried by the 4871 object instance of this class. Values include: 4873 0: Undefined 4874 1: String 4875 2: Integer 4876 3: Boolean 4877 4: Floating Point 4878 5: DateTime 4880 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" 4882 This is a mandatory attribute that defines an array of strings. 4883 Each string in the array represents an attribute name and value 4884 of an Event object. The format of each string is defined as 4885 name:value. The 'name' part is the name of the SUPAPolicyEvent 4886 attribute, and the 'value' part is the value of that attribute. 4888 For example, if this value of this attribute is: 4890 {(startTime:0800), (endTime:1700)} 4892 then this attribute contains two properties, called startTime and 4893 endTime, whose values are 0800 and 1700, respectively. 4895 Note that the supaPolicyEventEncoding class attribute defines how 4896 to interpret the value portion of this attribute. 4898 This attribute works with another class attribute, called 4899 supaPolicyEventEncoding, which defines how to interpret this 4900 attribute. These two attributes form a tuple, and together enable 4901 a machine to understand the syntax and value of the data carried 4902 by the object instance of this class. 4904 6.11.2. SUPAPolicyEvent Relationships 4906 No relationships are currently defined for this class. It inherits 4907 the relationships defined by the SUPAPolicyComponentDecorator (see 4908 section 5.7.3.). 4910 6.12. The Concrete Class "SUPAPolicyCondition" 4912 This is a mandatory concrete class that represents the concept of 4913 an Condition that will determine whether or not the set of Actions 4914 in the SUPAECAPolicyRule to which it belongs are executed or not. 4915 SUPAPolicyConditions can be used as part of a SUPAPolicyClause 4916 (e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or as a 4917 stand-alone SUPAPolicyClause (e.g., the supaPolicyConditionData 4918 attribute contains text that defines the entire condition clause). 4920 6.12.1. SUPAPolicyCondition Attributes 4922 Currently, two attributes are defined for the SUPAPolicyCondition 4923 class, which are described in the following subsections. 4925 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 4927 This is a mandatory array of string attributes that contains the 4928 content of this SUPAPolicyCondition object. 4930 This attribute works with another class attribute, called 4931 supaPolicyConditionEncoding, which defines how to interpret this 4932 attribute. These two attributes form a tuple, and together enable 4933 a machine to understand the syntax and value of the data carried 4934 by the object instance of this class. 4936 6.12.1.2. The Attribute "supaPolicyConditionEncoding" 4938 This is a mandatory non-zero enumerated integer attribute, and 4939 defines the data type of the supaPolicyConditionData attribute. 4940 These two attributes form a tuple, and together enable a machine 4941 to understand the syntax and value of the content of this 4942 SUPAPolicyCondition object. Values include: 4944 0: undefined 4945 1: String 4946 2: OCL 2.x 4947 3: OCL 1.x 4948 4: QVT 1.2 - Relations Language 4949 5: QVT 1.2 - Operational language 4950 6: Alloy 4952 6.12.2. SUPAPolicyEvent Relationships 4954 No relationships are currently defined for this class. It inherits 4955 the relationships defined by the SUPAPolicyComponentDecorator (see 4956 section 5.7.3.). 4958 6.13. The Concrete Class "SUPAPolicyAction" 4960 This is a mandatory concrete class that represents the concept of 4961 an Action, which is a part of a SUPAECAPolicyRule, which may be 4962 executed when both the event and the condition clauses of its 4963 owning SUPAECAPolicyRule evaluate to true. The execution of this 4964 action is determined by its SUPAECAPolicyRule container, and any 4965 applicable SUPAPolicyMetadata objects. SUPAPolicyActions can be 4966 used in three different ways: 4968 o as part of a SUPAPolicyClause (e.g., var = 4969 SUPAPolicyAction.supaPolicyActionData) 4970 o as a stand-alone SUPAPolicyClause (e.g., the 4971 supaPolicyActionData attribute contains text that defines 4972 the entire action clause) 4973 o to invoke a SUPAECAPolicyRule 4975 In the third case, the execution semantics SHOULD be to suspend 4976 the current execution of the set of SUPAPolicyActions that are 4977 executing, transfer execution control to the invoked 4978 SUPAECAPolicyRule, and resume the execution of the original set 4979 of SUPAPolicyActions when the invoked SUPAECAPolicyRule has 4980 finished execution. 4982 6.13.1. SUPAPolicyAction Attributes 4984 Currently, two attributes are defined for the SUPAPolicyCondition 4985 class, which are described in the following subsections. 4987 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" 4989 This is a mandatory array of string attributes that contains the 4990 content of this SUPAPolicyAction object. This attribute works with 4991 another class attribute, called supaPolicyActionEncoding, which 4992 defines how to interpret this attribute. These two attributes form 4993 a tuple, and together enable a machine to understand the syntax 4994 and value of the data carried by the object instance of this class. 4996 Since this attribute could represent a term in a SUPAPolicyClause 4997 (e.g., var = SUPAPolicyAction.supaPolicyActionData), a complete 4998 SUPAPolicyClause (e.g., the supaPolicyActionData attribute 4999 contains text that defines the entire action clause), or the 5000 name of a SUPAECAPolicyRule to invoke, each element in the string 5001 array is prepended with one of the following strings: 5003 o 't:' (or 'term:'), to denote a term in a SUPAPolicyClause 5004 o 'c:' (or 'clause:'), to denote an entire SUPAPolicyClause 5005 o 'r:' (or 'rule:'), to invoke a SUPAECAPolicyRule 5007 6.13.1.2. The Attribute "supaPolicyActionEncoding" 5009 This is a mandatory non-zero enumerated integer attribute, and 5010 defines the data type of the supaPolicyActionData attribute. This 5011 attribute works with another class attribute, called 5012 supaPolicyActionData, which contains the content of the action. 5013 These two attributes form a tuple, and together enable a machine 5014 to understand the syntax and value of the content of this 5015 SUPAPolicyAction object. Values include: 5017 0: undefined 5018 1: GUID 5019 2: UUID 5020 3: URI 5021 4: FQDN 5022 5: String 5023 6: OCL 2.x 5024 7: OCL 1.x 5025 8: QVT 1.2 - Relations Language 5026 9: QVT 1.2 - Operational language 5027 10: Alloy 5029 6.13.2. SUPAPolicyAction Relationships 5031 No relationships are currently defined for this class. It inherits 5032 the relationships defined by the SUPAPolicyComponentDecorator (see 5033 section 5.7.3.). 5035 Enumerations 1-4 are used to provide a reference to an action 5036 object. Enumerations 5-10 are used to express the action to 5037 perform as a string. 5039 7. Examples 5041 This will be defined in the next version of this document. 5043 8. Security Considerations 5045 This will be defined in the next version of this document. 5047 9. IANA Considerations 5049 This document has no actions for IANA. 5051 10. Acknowledgments 5053 This document has benefited from reviews, suggestions, comments 5054 and proposed text provided by the following members, listed in 5055 alphabetical order: Andy Bierman, Bob Natale, Fred Feisullin, 5056 Georgios Karagiannis, Liu (Will) Shucheng, Marie-Jose Montpetit. 5058 11. References 5060 This section defines normative and informative references for this 5061 document. 5063 11.1. Normative References 5065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5066 Requirement Levels", BCP 14, RFC 2119, March 1997. 5068 [RFC3060] Moore, B., Ellesson, E., Strassner, J., Westerinen, 5069 A., "Policy Core Information Model -- Version 1 5070 Specification", RFC 3060, February 2001 5072 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 5073 Scherling, M., Quinn, B., Herzog, S., Huynh, A., 5074 Carlson, M., Perry, J., Waldbusser, S., "Terminology 5075 for Policy-Based Management", RFC 3198, November, 2001 5077 [RFC3460] Moore, B., ed., "Policy Core Information Model (PCIM) 5078 Extensions, RFC 3460, January 2003 5080 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for 5081 the Network Configuration Protocol (NETCONF)", 5082 RFC 6020, October 2010. 5084 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 5085 October 2010. 5087 11.2. Informative References 5089 [1] Strassner, J., "Policy-Based Network Management", 5090 Morgan Kaufman, ISBN 978-1558608597, Sep 2003 5092 [2] Strassner, J., ed., "The DEN-ng Information Model", 5093 add stable URI 5095 [3] Riehle, D., "Composite Design Patterns", Proceedings 5096 of the 1997 Conference on Object-Oriented Programming 5097 Systems, Languages and Applications (OOPSLA '97). 5098 ACM Press, 1997, Page 218-228 5100 [4] DMTF, CIM Schema, v2.44, 5101 http://dmtf.org/standards/cim/cim_schema_v2440 5103 [5] Strassner, J., ed., "ZOOM Policy Architecture and 5104 Information Model Snapshot", TR235, part of the 5105 TM Forum ZOOM project, October 26, 2014 5107 [6] TM Forum, "Information Framework (SID), GB922 and 5108 associated Addenda, v14.5, 5109 https://www.tmforum.org/information-framework-sid/ 5111 [7] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 5112 subtyping", ACM Transactions on Programming languages 5113 and Systems 16 (6): 1811 - 1841, 1994 5115 [8] Klyus, M., Strassner, J., editors, "SUPA Proposition", 5116 IETF Internet draft, draft-klyus-supa-proposition-01, 5117 July 18015 5119 [9] ISO/IEC 10746-3 (also ITU-T Rec X.903), "Reference 5120 Model Open Distributed Processing Architecture", 5121 April 20, 2010 5123 [10] Davy, S., Jennings, B., Strassner, J., "The Policy 5124 Continuum - A Formal Model", Proc. of the 2nd Intl. 5125 IEEE Workshop on Modeling Autonomic Communication 5126 Environments (MACE), Multicon Lecture Notes, No. 6, 5127 Multicon, Berlin, 2007, pages 65-78 5129 [11] Gamma, E., Helm, R., Johnson, R., Vlissides, J., 5130 "Design Patterns - Elements of Reusable Object-Oriented 5131 Software", Addison-Wesley, 1994, ISBN 0-201-63361-2 5133 [12] Strassner, J., de Souza, J.N., Raymer, D., Samudrala, 5134 S., Davy, S., Barrett, K., "The Design of a Novel 5135 Context-Aware Policy Model to Support Machine-Based 5136 Learning and Reasoning", Journal of Cluster Computing, 5137 Vol 12, Issue 1, pages 17-43, March, 2009 5139 [13] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 5140 subtyping", ACM Transactions on Programming languages 5141 and Systems, 16 (6): 1811 - 1841, 1994 5143 [14] Martin, R.C., "Agile Software Development, Principles, 5144 Patterns, and Practices", Prentice-Hall, 2002, 5145 ISBN: 0-13-597444-5 5147 Authors' Addresses 5149 John Strassner 5150 Huawei Technologies 5151 2330 Central Expressway 5152 Santa Clara, CA 95138 USA 5153 Email: john.sc.strassner@huawei.com 5155 Joel Halpern 5156 Ericsson 5157 P. O. Box 6049 5158 Leesburg, VA 20178 5159 Email: joel.halpern@ericsson.com 5161 Jason Coleman 5162 Cisco Systems 5163 124 Copper Lake Lane 5164 Georgetown Tx 78628 5165 Email: routerjockey@me.com 5167 Appendix A. Brief Analyses of Previous Policy Work 5169 This appendix describes of some of the important problems with 5170 previous IETF policy work., and describes the rationale for 5171 taking different design decisions in this document. 5173 A.1. PolicySetComponent vs. SUPAPolicyStructure 5175 The ability to define different types of policy rules is not 5176 present in [RFC3060] and [RFC3460], because both are based on [4], 5177 and this ability is not present in [4]. [RFC3060], [RFC3460], and 5178 [4] are all limited to CA (condition-action) policy rules. In 5179 addition, events are NOT defined. These limitations mean that 5180 RFC3060], [RFC3460], and [4] can only represent CA Policy Rules. 5182 In contrast, the original design goal of SUPA was to define a 5183 single class hierarchy that could represent different types of 5184 policies (e.g., imperative and declarative). Hence, it was 5185 decided to make SUPAPolicyStructure generic in nature, so that 5186 different types of policies could be defined as subclasses. This 5187 enables a single Policy Framework to support multiple types of 5188 policies. 5190 A.2. Flat Hierarchy vs. SUPAPolicyComponentStructure 5192 Figure 26 shows a portion of the class hierarchy of [RFC3460]. 5194 A 5195 +--------+ 5196 | Policy | 5197 +----+---+ 5198 / \ 5199 | 5200 | 5201 +---------+------+------+------------+-----------+ 5202 | | | | | 5203 A | | A | | A | 5204 +-----+-----+ | +--------+--------+ | +------+-------+ 5205 | PolicySet | | | PolicyCondition | | | PolicyAction | 5206 +-----+-----| | +--------+--------+ | +------+-------+ 5207 / \ | / \ | / \ 5208 | | | | | 5209 ... | ... | ... 5210 A | A | 5211 +-------+--------+ +-------+-----+ 5212 | PolicyVariable | | PolicyValue | 5213 +-------+--------+ +-------+-----+ 5214 / \ / \ 5215 | | 5216 ... ... 5218 Figure 26. Simplified Class Hierarcy of [RFC3460] 5220 RFC3060], [RFC3460], and [4] defined PolicyConditions and 5221 PolicyActions as subclasses of Policy (along with PolicySet, 5222 which is the superclass of PolicyRules and PolicyGroups). This 5223 means that there is no commonality between PolicyConditions and 5224 PolicyActions, even though they are both PolicyRule components. 5225 From an object-oriented point-of-view, this is incorrect, since a 5226 PolicyRule aggregates both PolicyConditions and PolicyActions. 5228 In addition, note that both PolicyVariables and PolicyValues are 5229 siblings of PolicyRules, PolicyConditions, and PolicyActions. This 5230 is incorrect for several reasons: 5232 o a PolicyRule cannot rectly contain PolicyVariables or 5233 PolicyValues, so they shouldn't be at the same level of the 5234 class hierarchy 5235 o both PolicyConditions and PolicyActions can contain 5236 PolicyVariables and PolicyValues, which implies that both 5237 PolicyVariables and PolicyValues should be lower in the 5238 class hierarchy 5240 Note that in the current version of [4], PolicyVariable and 5241 PolicyValue are both deleted. There are other changes as well, 5242 but they are beyond the scope of this Appendix. 5244 The original design goal of SUPA was to define a single class 5245 hierarchy that could represent different types of policies and 5246 policy components. This cannot be accomplished in [RFC3460], since 5247 there is no notion of a policy component (or alternatively, 5248 PolicyCondition, PolicyAction, PolicyVariable, and PolicyValue are 5249 all components at the same abstraction level, which is clearly not 5250 correct). Hence, SUPA defined the SUPAPolicyComponentStructure 5251 class to capture the concept of a reusable policy component. 5253 In summary, SUPAPolicyStructure subclasses define the structure of 5254 a policy in a common way, while SUPAPolicyComponentStructure 5255 subclasses define the content that is contained in the structure 5256 of a policy, also in a common way. 5258 A.3. PolicyRules and PolicyGroups vs. SUPAPolicyRules 5260 A PolicySetComponent is an aggregation, implemented as an 5261 association class, that "collects instances of PolicySet 5262 subclasses into coherent sets of Policies". This is a recursive 5263 aggregation, with multiplicity 0..n - 0..n, on the PolicySet 5264 class. 5266 Since this is a recursive aggregation, it means that a PolicySet 5267 can aggregate zero or more PolicySets. This is under-specified, 5268 and can be interpreted in one of two ways: 5270 1. A PolicySet subclass can aggregate any PolicySet subclass 5271 (PolicyRules can aggregate PolicyRules and PolicyGroups, and 5272 vice-versa) 5273 2. PolicyRules can aggregate PolicyRules, and PolicyGroups can 5274 aggregate PolicyGroups, but neither class can aggregate the 5275 other type of class 5277 Both interpretations are ill-suited for policy-based management. 5278 The problem with the first is that if PolicyGroup is the mechanism 5279 for grouping, why can a PolicyRule aggregate a PolicyGroup? This 5280 implies that PolicyGroups are not needed. The problem with the 5281 second is that PolicyGroups cannot aggregate PolicyRules (which 5282 again implies that PolicyGroups are not needed). 5284 Furthermore, there are no mechanisms defined in the [RFC3460] 5285 model to prevent loops of PolicyRules. This is a problem, because 5286 EVERY PolicyRule and PolicyGroup inherits this recursive 5287 aggregation. 5289 This is why this document uses the composite pattern. First, this 5290 pattern clearly shows what object is aggregating what other 5291 object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate ability 5292 SUPAECAPolicyRuleComposite). Second, it does not allow ability 5293 SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule 5294 (this is discussed more in the following subsection). 5296 A.3.1. Sub-rules 5298 Sub-rules (also called nested policy rules) enable a policy rule to 5299 be contained within another policy rule. These have very complex 5300 semantics, are very hard to debug, and provide limited value. They 5301 also require a complex set of aggregations (see section A.4.). 5303 The main reason for defining sub-rules in [RFC3460] is to enable 5304 "complex policy rules to be constructed from multiple simpler 5305 policy rules". However, the composite pattern does this much more 5306 efficiently than a simple recursive aggregation, and avoids the 5307 ambiguous semantics of a recursive aggregation. This latter point 5308 is important, because if PolicyRule and/or PolicyGroup is 5309 subclassed, then all subclasses still inherit this recursive 5310 aggregation, along with its ambiguous semantics. 5312 A.4. PolicyConditions and PolicyActions vs. SUPAECAComponent 5314 There is no need to use the SimplePolicyCondition and 5315 ComplexPolicyCondition objects defined in [RFC3460], since the 5316 SUPAPolicyComponentStructure uses the decorator pattern (see 5317 section 5.7) to provide more extensible types of conditions than is 5318 possible with those classes. This also applies for the 5319 SimplePolicyAction and the ComplexPolicyAction classes defined in 5320 [RFC3460]. 5322 More importantly, this removes the need for a complex set of 5323 aggregations (i.e., PolicyComponent, PolicySetComponent, 5324 PolicyConditionStructure, PolicyConditionInPolicyRule, 5325 PolicyConditionInPolicyCondition, PolicyActionStructure, 5326 PolicyActionInPolicyRule, and PolicyActionInPolicyAction). 5327 Instead, ANY SUPAECAComponent is defined as a decorator (i.e., ability 5328 subclass of SUPAPolicyComponentDecorator), and hence, Any 5329 SUPAECAComponent is wrapped onto a concrete subclass of 5330 SUPAPolicyClause using the SAME aggregation 5331 (SUPAHasDecoratedPolicyComponent). This is a significantly simpler 5332 design that is also more powerful. 5334 A.5. The SUPAPolicyComponentDecorator Abstraction 5336 One of the problems in building a policy model is the tendency to 5337 have a multitude of classes, and hence object instances, to 5338 represent different combinations of policy events, conditions, and 5339 actions. This can lead to class and/or relationship explosion, as 5340 is the case in [RFC3460], [4], and [6]. 5342 For example, [RFC3460] defines five subclasses of PolicyCondition: 5343 PolicyTimePeriodCondition, VendorPolicyCondition, 5344 SimplePolicyCondition, CompoundPolicyCondition, and 5345 CompoundFilterCondition. Of these: 5347 o PolicyTimePeriodCondition is a data structure, not a class 5348 o VendorPolicyCondition represents a condition using two 5349 attributes that represent a multi-valued octet string 5350 o SimplePolicyCondition, CompoundPolicyCondition, and 5351 CompoundFilterCondition all have ambiguous semantics 5353 SimplePolicyCondition represents an ordered 3-tuple, in the form 5354 {variable, match, value}. However, the match operator is not 5355 formally modeled. Specifically, "the 'match' relationship is to 5356 be interpreted by analyzing the variable and value instances 5357 associated with the simple condition". This becomes problematic 5358 for several cases, such as shallow vs. deep object comparisons. 5359 More importantly, this requires two separate aggregations 5360 (PolicyVariableInSimplePolicyCondition and 5361 PolicyValueInSimplePolicyCondition) to associate variables and 5362 values to the SimplePolicyCondition, respectively. Since [RFC3460] 5363 defines all relationships as classes, this means that the 5364 expression "Foo > Bar" requires a total of FIVE objects (one each 5365 for the variable and value, one for the SimplePolicyCondition, and 5366 one each to associate the variable and value with the 5367 SimplePolicyCondition). 5369 This is exacerbated when SimplePolicyConditions are used to build 5370 CompoundPolicyConditions. In addition to the above complexity 5371 (which is required for each SimplePolicyCondition), a new 5372 aggregation (PolicyConditionInPolicyCondition) is required to 5373 aggregation PolicyConditions. Thus, the compound expression: 5374 "((Foo > Bar) AND (Foo < Baz))" requires a total of THIRTEEN 5375 objects (five for each of the terms being ANDed, plus one for the 5376 CompoundPolicyCondition, and two to aggregate each term to the 5377 CompoundPolicyCondition). 5379 Note that in the above examples, the superclasses of each of the 5380 relationships are omitted for clarity. In addition, [RFC3460] is 5381 built using inheritance; this means that if a new function is 5382 required, a new class must be built (e.g., CompoundFilterCondition 5383 is a subclass, but all it adds is one attribute). 5385 In constrast, the Decorator Pattern enables behavior to be 5386 selectively added to an individual object, either statically or 5387 dynamically, without having to build association classes. In 5388 addition, the decorator pattern uses composition, instead of 5389 inheritance, to avoid class explosion. This means that a new 5390 variable, value, or even condition class can be defined at 5391 runtime, and then all or part of that class can dynamically wrap 5392 an existing object without need for recompilation and 5393 redeployment. 5395 A.6. The Abstract Class "SUPAPolicyClause" 5397 This abstraction is missing in [RFC3060], [RFC3460], [4], and [6]. 5398 SUPAPolicyClause was abstracted from DEN-ng [2], and a version of 5399 this class is in the process of being added to [5]. However, the 5400 class and relationship design in [5] differs significantly from 5401 the corresponding designs in this document. 5403 SUPAPolicyClause further reinforces the different between a policy 5404 rule and a component of a policy rule by abstracting the content 5405 of a policy rule as a reusable object. This is fundamental for 5406 enabling different types of policy rules (e.g., imperative and 5407 declarative) to to be represented using the same constructs. 5409 A.7. Problems with the RFC3460 Version of PolicyVariable 5411 The following subsections define a brief, and incomplete, set of 5412 problems with the implementation of [RFC3460] (note that [RFC3060 5413 did not define variables, operators, and/or values). 5415 A.7.1. Object Bloat 5417 [RFC3460] used two different and complex mechanisms for providing 5418 generic get and set expressions. PolicyVariables were subclassed 5419 into two subclasses, even though they performed the same semantic 5420 function. This causes additional problems: 5422 o PolicyExplicitVariables are for CIM compatibility; note that 5423 the CIM does not contain either PolicyVariables or 5424 PolicyValues ([4]) 5425 o PolicyImplicitVariable subclasses do not define attributes; 5426 rather, they are bound to an appropriate subclass of 5427 PolicyValue using an association 5429 Hence, defining a variable is relatively expensive in [RFC3460], 5430 as in general, two objects and an association must be used. The 5431 objects themselves do not define content; rather, their names are 5432 used as a mechanism to identify an object to match. This means 5433 that an entire object must be used (instead of, for example, an 5434 attribute), which is wasteful. It also make it difficult to 5435 adjust constraints at runtime, since the constraint is defined in 5436 a class that is statically defined (and hence, requires 5437 recompilation and possibly redeployment if it is changed). 5439 A.7.2. Object Explosion 5441 The above three problems lead to class explosion (recall that in 5442 [RFC3060], [RFC3460], and [4], associations are implemented as 5443 classes). 5445 In contrast to this approach, the approach in this document keeps 5446 the idea of the class hierarchy for backwards compatibility, but 5447 streamlines the implementation. Specifically: 5449 1. The decorator pattern is an established and very used 5450 software pattern (it dates back to at least 1994 [11]). 5451 2. The use of a single association class 5452 (i.e., SUPAHasDecoratedPolicyComponentDetail) can represent 5453 more constraints than is possible in the approaches of 5454 [RFC3460] and [4] in a much more flexible manner, due to its 5455 function as a decorator of other objects. 5456 3. Note that there is no way to enforce the constraint matching 5457 in [RFC3460] and [6]; the burden is on the developer to 5458 check and see if the constraints specified in one class are 5459 honored in the other class. 5460 4. If these constraints are not honored, there is no mechanism 5461 specified to define the clause as incorrectly formed. 5463 A.7.3. Specification Ambiguities 5465 There are a number of ambiguities in [RFC2460]. 5467 First, [RFC3460] says: "Variables are used for building individual 5468 conditions". While this is true, variables can also be used for 5469 building individual actions. This is reflected in the definition 5470 for SUPAPolicyVariable. 5472 Second, [RFC3460] says: "The variable specifies the property of a 5473 flow or an event that should be matched when evaluating the 5474 condition." While this is true, variables can be used to test many 5475 other things than "just" a flow or an event. This is reflected in 5476 the SUPAPolicyVariable definition. 5478 Third, the [RFC3460] definition requires the use of associations 5479 in order to properly constrain the variable (e.g., define its 5480 data type, the range of its allowed values, etc.). This is both 5481 costly and inefficient. 5483 Fourth, [RFC3460] is tightly bound to the DMTF CIM schema [4]. 5484 The CIM is a data model (despite its name), because: 5486 o It uses keys and weak relationships, which are both concepts 5487 from relational algebra and thus, not technology-independent 5488 o It has its own proprietary modeling language 5489 o It contains a number of concepts that are not defined in UML 5490 (including overriding keys for subclasses) 5492 Fifth, the class hierarchy has two needless classes, called 5493 SUPAImplicitVariable and SUPAExplicitVariable. These classes do 5494 not define any attributes or relationships, and hence, do not 5495 add any semantics to the model. 5497 Finally, in [RFC3460], defining constraints for a variable is 5498 limited to associating the variable with a PolicyValue. This is 5499 both cumbersome (because associations are costly; for example, 5500 they equate to a join in a relational database management system), 5501 and not scalable, because it is prone to proliferating PolicyValue 5502 classes for every constraint (or range of constraints) that is 5503 possible. Therefore, in SUPA, this mechanism is replaced with 5504 using an association to an association class that defines 5505 constraints in a much more general and powerful manner (i.e., 5506 the SUPAHasDecoratedPolicyComponentDetail class). 5508 A.8. Problems with the RFC3460 Version of PolicyValue 5510 The following subsections define a brief, and incomplete, set of 5511 problems with the implementation of [RFC3460] (note that [RFC3060 5512 did not define variables, operators, and/or values). 5514 A.8.1. Object Bloat 5516 [RFC3460] defined a set of 7 subclasses; three were specific to 5517 networking (i.e., IPv4 Address, IPv6 Address, MAC Address) and 4 5518 (PolicyStringValue, PolicyBitStringValue, PolicyIntegerValue, and 5519 PolicyBooleanValue) were generic in nature. However, each of these 5520 objects defined a single class attribute. This has the same two 5521 problems as with PolicyVariables (see section 5.9.1.1): 5523 1. Using an entire object to define a single attribute is very 5524 wasteful and expensive 5525 2. It also make it difficult to adjust constraints at runtime, 5526 since the constraint is defined in a class that is statically 5527 defined (and hence, requires recompilation and possibly 5528 redeployment if it is changed). 5530 A.8.2. Object Explosion 5532 [RFC3460] definition requires the use of associations 5533 in order to properly constrain the variable (e.g., define its 5534 data type, the range of its allowed values, etc.). This is both 5535 costly and inefficient (recall that in [RFC3060], [RFC3460], and 5536 [4], associations are implemented as classes). 5538 A.8.3. Lack of Constraints 5540 There is no generic facility for defining constraints for a 5541 PolicyValue. Therefore, there is no facility for being able to 5542 change such constraints dynamically at runtime. 5544 A.8.4. Tightly Bound to the CIM Schema 5546 [RFC3460] is tightly bound to the DMTF CIM schema [4]. The CIM is 5547 a data model (despite its name), because: 5549 o It uses keys and weak relationships, which are both concepts 5550 from relational algebra and thus, not technology-independent 5551 o It has its own proprietary modeling language 5552 o It contains a number of concepts that are not defined in UML 5553 (including overriding keys for subclasses) 5555 A.8.5. Specification Ambiguity 5557 [RFC3460] says: It is used for defining values and constants used 5558 in policy conditions". While this is true, variables can also be 5559 used for building individual actions. This is reflected in the 5560 SUPAPolicyVariable definition. 5562 A.8.6. Lack of Symmetry 5564 Most good information models show symmetry between like components. 5565 [RFC3460] has no symmetry in how it defines variables and values. 5566 In contrast, this document recognizes that variables and values 5567 are just terms in a clause; hence, the only difference in the 5568 definition of the SUPAPolicyVariable and SUPAPolicyValue classes 5569 is that the content attribute in the former is a single string, 5570 whereas the content attribute in the latter is a string array. 5571 In particular, the semantics of both variables and values are 5572 defined using the decorator pattern, along with the attributes of 5573 the SUPAPolicyComponentDecorator and the 5574 SUPAHasDecoratedPolicyComponentDetail classes. 5576 Appendix B. Mathematical Logic Terminology and Symbology 5578 Appendix C. SUPA Logic Statement Information Model