idnits 2.17.1 draft-strassner-supa-generic-policy-info-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters 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 -- The document date (July 4, 2015) is 3219 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: '3060' is mentioned on line 2465, but not defined == Unused Reference: 'RFC6020' is defined on line 3515, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 3519, 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: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Strassner 2 Internet Draft Huawei Technologies 3 Intended status: Standard Track 4 Expires: January 4, 2016 July 4, 2015 6 Generic Policy Information Model for 7 Simplified Use of Policy Abstractions (SUPA) 8 draft-strassner-supa-generic-policy-info-model-02 10 Abstract 12 Simplified Use of Policy Abstractions (SUPA) defines an interface 13 to a network management function that takes high-level, possibly 14 network-wide policies as input and creates element configuration 15 snippets as output. SUPA addresses the needs of operators and 16 application developers to represent multiple types of policy 17 rules, which vary in the level of abstraction, to suit the needs 18 of different actors. This document defines a single common 19 extensible framework for representing different types of policy 20 rules, in the form of a set of information model fragments, that 21 is independent of language, protocol, repository, and the level 22 of abstraction of the content of the policy rule. This enables a 23 common set of concepts defined in this set of information models 24 to be mapped into different data models that use different 25 languages, protocols, and repositories to optimize their usage. 26 The definition of common policy concepts also provides better 27 interoperability by ensuring that each data model can share a set 28 of common concepts, independent of its level of detail or the 29 language, protocol, and/or repository that it is using. 31 Specifically, this document defines three information models: 33 1. A framework for defining the concept of policy, 34 independent of how policy is represented or used; this is 35 called the SUPA Generic Policy Information Model (GPIM) 36 2. A framework for defining a policy model that uses the 37 event-condition-action paradigm; this is called the SUPA 38 Eca Policy Rule Information Model (EPRIM) 39 3. A framework for defining a policy model that uses a 40 declarative (e.g., intent-based) paradigm; this is called 41 the SUPA Logic Statement Information Model (LSIM) 43 The combination of the GPIM and the EPRIM, or the GPIM and the 44 LSIM, provide an extensible framework for defining policy that 45 uses an event-condition-action or declarative representation that 46 is independent of data repository, data definition language, query 47 language, implementation language, and protocol. A specific design 48 goal of SUPA is to enable ECA policy rules and declarative policy 49 statements to be used together or separately. This is achieved by 50 deriving both the EPRIM and the LSIM from the GPIM. 52 Status of this Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF), its areas, and its working groups. Note that 59 other groups may also distribute working documents as Internet- 60 Drafts. 61 Internet-Drafts are draft documents valid for a maximum of six 62 months and may be updated, replaced, or obsoleted by other 63 documents at any time. It is inappropriate to use Internet-Drafts 64 as reference material or to cite them other than as "work in 65 progress." 67 The list of current Internet-Drafts can be accessed at 68 http://www.ietf.org/ietf/1id-abstracts.txt 70 The list of Internet-Draft Shadow Directories can be accessed at 71 http://www.ietf.org/shadow.html 73 This Internet-Draft will expire on October 26, 2015. 75 Copyright Notice 77 Copyright (c) 2014 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with 85 respect to this document. Code Components extracted from this 86 document must include Simplified BSD License text as described in 87 Section 4.e of the Trust Legal Provisions and are provided 88 without warranty as described in the Simplified BSD License. 90 Table of Contents 92 1. Introduction ................................................. 8 93 2. Conventions Used in This Document ............................ 8 94 3. Terminology .................................................. 8 95 3.1. Acronyms................................................. 8 96 3.2. Definitions ............................................. 9 98 Table of Contents (continued) 100 3.2.1. Core Terminology ................................... 9 101 3.2.1.1. Information Model ............................. 9 102 3.2.1.2. Data Model ................................... 10 103 3.2.1.3. Container .................................... 10 104 3.2.1.4. PolicyContainer .............................. 10 105 3.2.2. Policy Terminology ................................ 10 106 3.2.2.1. SUPAPolicy ................................... 11 107 3.2.2.2. SUPAPolicyStatement .......................... 11 108 3.2.2.3. SUPAECAPolicyRule ............................ 11 109 3.2.2.4. SUPALogicStatement ........................... 11 110 3.2.2.5. SUPAMetadata ................................. 12 111 3.2.2.6. SUPAPolicyTarget ............................. 12 112 3.2.2.7. SUPAPolicySubject ............................ 12 113 3.2.3. Modeling Terminology .............................. 13 114 3.2.3.1. Inheritance .................................. 13 115 3.2.3.2. Relationship ................................. 13 116 3.2.3.3. Association .................................. 13 117 3.2.3.4. Aggregation .................................. 13 118 3.2.3.5. Composition .................................. 14 119 3.2.3.6. Association Class ............................ 14 120 3.2.3.7. Multiplicity ................................. 14 121 3.2.3.8. Navigability ................................. 14 122 3.2.3.9. Abstract Class ............................... 15 123 3.2.3.10. Concrete Class .............................. 15 124 3.2.4. Mathematical Logic Terminology ................... 15 125 3.2.4.1. Predicate .................................... 15 126 3.2.4.2. Logic Operators .............................. 15 127 3.2.4.2.1. Propositional Logic Connectives ......... 15 128 3.2.4.2.2. First Order Logic Quantifiers ........... 16 129 3.2.4.3. Propositional Logic .......................... 16 130 3.2.4.4. First-Order Logic ............................ 16 131 3.3. Symbology .............................................. 17 132 3.3.1. Inheritance ....................................... 17 133 3.3.2. Association ....................................... 17 134 3.3.3. Aggregation ....................................... 17 135 3.3.4. Composition ....................................... 18 136 3.3.5. Association Class ................................. 18 137 3.3.6. Logical Connectives ............................... 18 138 3.3.7. Quantifiers ....................................... 18 139 4. Policy Abstraction Architecture ............................. 19 140 4.1. Motivation ............................................. 20 141 4.2. SUPA Approach .......................................... 21 142 4.3. SUPA Generic Policy Information Model Overview ......... 21 143 4.4. Structure of SUPA Policies ............................. 24 144 4.4.1. ECA Policy Rule Structure ......................... 24 145 4.4.2. Logical Statement Structure ....................... 25 146 4.5. GPIM Assumptions ....................................... 27 147 4.6. Scope of Previous Work ................................. 28 149 Table of Contents (continued) 151 5. GPIM Model .................................................. 29 152 5.1. Overview ............................................... 29 153 5.2. The Abstract Class "SUPAPolicy" ........................ 29 154 5.2.1. SUPAPolicy Attributes ............................. 32 155 5.2.1.1. The Attribute "supaObjectIDContent" .......... 32 156 5.2.1.2. The Attribute "supaObjectIDFormat" ........... 32 157 5.2.1.3. The Attribute "supaPolicyDescription" ........ 32 158 5.2.1.4. The Attribute "supaPolicyName" ............... 32 159 5.2.2. SUPAPolicy Relationships .......................... 33 160 5.2.2.1. The Relationship "SUPAPolicyMetadata" ........ 33 161 5.2.2.2. The Association Class 162 "SUPAPolicyMetadataDetail" ................... 33 163 5.3. The Abstract Class "SUPAPolicyAtomic" .................. 33 164 5.3.1. SUPAPolicyAtomic Attributes ....................... 34 165 5.3.1.1. The Attribute "supaPolicyDeployStatus" ....... 34 166 5.3.1.2. The Attribute "supaPolicyExecStatus" ......... 34 167 5.3.2. SUPAPolicyAtomic Relationships .................... 34 168 5.3.2.1. The Aggregation "SUPAPAHasPolicyStmts" ....... 34 169 5.3.2.2. The Association Class 170 "SUPAPAHasPolicyStmtDetail" .................. 35 171 5.4. The Concrete Class "SUPAPolicyComposite" ............... 35 172 5.4.1. SUPAPolicyComposite Attributes .................... 35 173 5.4.1.1. The Attribute "supaPCFailureStrategy" ........ 36 174 5.4.1.2. The Attribute "supaPCIsMatchAll" ............. 36 175 5.4.2. SUPAPolicyComposite Relationships ................. 36 176 5.4.2.1. The Aggregation "HasSUPAPolicies" ............ 36 177 5.4.2.2. The Association Class "HasSUPAPolicyDetail" .. 37 178 5.5. The Abstract Class "SUPAPolicyStatement" ............... 37 179 5.5.1. SUPAPolicyStatement Attributes .................... 39 180 5.5.1.1. The Attribute "supaPolStmtAdminStatus" ....... 39 181 5.5.1.2. The Attribute "supaPolStmtExecStatus" ........ 40 182 5.5.1.3. The Attribute "supaPolStmtIsCNF" ............. 40 183 5.5.2. SUPAPolicyStatement Subclasses .................... 40 184 5.5.2.1. The Concrete Class "SUPAEncodedClause" ....... 41 185 5.5.2.1.1. SUPAEncodedClause Attributes ............ 42 186 5.5.2.1.1.1. The Attribute "supaClauseContent" .. 42 187 5.5.2.1.1.2. The Attribute "supaClauseFormat" ... 42 188 5.5.2.1.1.3. The Attribute "supaClauseResponse" . 42 189 5.5.3. SUPAPolicyStatement Relationships ................. 43 190 5.5.3.1. The Aggregation "SUPAPolicyTermsInStmt" ...... 43 191 5.5.3.2. The Association Class 192 "SUPAPolicyTermsInStmtDetail" ................ 43 193 5.5.3.2.1. SUPAPolicyStmtDetail Attributes ......... 43 194 5.6. The Abstract Class "SUPAPolicySubject" ................. 43 195 5.6.1. SUPAPolicySubject Attributes ...................... 45 196 5.6.1.1. The Attribute 197 "supaPolicySubjectIsAuthenticated" ........... 45 199 Table of Contents (continued) 201 5.6.2. SUPAPolicySubject Relationships ................... 45 202 5.6.2.1. The Relationship "SUPAPolicySubjects" ........ 45 203 5.6.2.2. The Association Class 204 "SUPAPolicySubjectDetail" ................... 46 205 5.6.2.2.1. SupaPolicySubjectDetail Attributes ...... 46 206 5.6.2.2.1.1. The Attribute 207 "supaPolicySubjectIsVerified" ........... 46 208 5.7. The Abstract Class "SUPAPolicyTarget" .................. 46 209 5.7.1. SUPAPolicyTarget Attributes ....................... 47 210 5.7.2. SUPAPolicyTarget Relationships .................... 47 211 5.7.2.1. The Relationship "SUPAPolicyTargets" ......... 47 212 5.7.2.2. The Association Class "SUPAPolicyTargetDetail" 47 213 5.7.2.2.1. SupaPolicyTargetDetail Attributes ....... 47 214 5.7.2.2.1.1. The Attribute 215 "supaPolicyTargetEnabled" .......... 47 216 5.8. The Abstract Class "SUPAPolicyTerm" .................... 48 217 5.8.1. SUPAPolicyTerm Attributes ......................... 49 218 5.8.1.1 The Attribute "supaTermIsNegated" ............. 49 219 5.8.2. SUPAPolicyTerm Relationships ...................... 49 220 5.8.2.1. The Aggregation "SUPAPolicyTermsInStmt" ...... 49 221 5.8.2.2. The Association Class 222 "SUPAPolicyTermsInStmtDetail" ................ 49 223 5.8.2.2.1. SUPAPolicyTermsInStmtDetail Attributes ..... 50 224 5.8.2.2.1.1. The Attribute 225 "supaPolTermOCLConstraint" ............ 50 226 5.8.3. SUPAPolicyTerm Subclasses ......................... 50 227 5.8.3.1. The Concrete Class "SUPAPolicyVariable" ...... 51 228 5.8.3.1.1. Problems with the RFC3460 Version of 229 PolicyVariable .......................... 51 230 5.8.3.1.2. SUPAPolicyVariable Attributes ........... 52 231 5.8.3.1.2.1. The Attribute 232 "supaAllowedValueTypes[0..n]" ...... 52 233 5.8.3.1.2.2. The Attribute "supaPolVarContent" .. 52 234 5.8.3.1.2.3. The Attribute "supaPolVarType" ..... 52 235 5.8.3.1.3. SUPAPolicyVariable Subclasses ........... 53 236 5.8.3.2. The Concrete Class "SUPAPolicyOperator" ...... 53 237 5.8.3.2.1. Problems with the RFC3460 Version ....... 53 238 5.8.3.2.2. SUPAPolicyOperator Attributes ........... 53 239 5.8.3.2.2.1. The Attribute "supaPolOpType" ...... 54 240 5.8.3.3. The Concrete Class "SUPAPolicyValue" ......... 54 241 5.8.3.3.1. Problems with the RFC3460 Version of 242 PolicyValue ............................. 55 243 5.8.3.3.2. SUPAPolicyValue Attributes .............. 55 244 5.8.3.3.2.1. The Attribute "supaPolValContent" .. 56 245 5.8.3.3.2.2. The Attribute "supaPolValType" ..... 56 246 5.8.3.3.3. SUPAPolicyValue Subclasses .............. 56 247 5.9. The Abstract Class "SUPAPolicyMetadata" ................ 56 248 5.9.1. SUPAPolicyMetadata Attributes ..................... 56 249 5.9.2. SUPAPolicyMetadata Relationships .................. 56 251 Table of Contents (continued) 253 6. SUPA ECAPolicyRule Information Model ........................ 57 254 6.1. Overview ............................................... 57 255 6.2. Constructing a SUPAECAPolicyRule ....................... 58 256 6.3. Working With SUPAECAPolicyRules ........................ 59 257 6.4. The Concrete Class "SUPAECAPolicyRule" ................. 60 258 6.4.1. SUPAECAPolicyRule Attributes ...................... 62 259 6.4.1.1. The Attribute "supaECAPolicyIsMandatory" ..... 62 260 6.4.1.2. The Attribute "supaECAPolicyPriority" ........ 62 261 6.4.2. SUPAECAPolicyRule Relationships ................... 63 262 6.4.2.1. The Aggregation "SUPAECAPolicyRules" ......... 63 263 6.4.2.1.1. The Association Class 264 "HasSUPAECAComponentDetail" ............. 63 265 6.4.3. SUPAECAPolicyRule Subclasses ...................... 63 266 6.4.3.1. The Concrete Class "SUPAECAPolicyRuleAtomic" . 64 267 6.4.3.1.1. SUPAECAPolicyRuleAtomic Attributes ...... 64 268 6.4.3.1.2. SUPAECAPolicyRuleAtomic Relationships ... 64 269 6.4.3.2. The Concrete Class 270 "SUPAECAPolicyRuleComposite" ................. 65 271 6.4.3.2.1. SUPAECAPolicyRuleAtomic Attributes ...... 65 272 6.4.3.2.1.1. The Attribute "supaECAEvalStrategy" 65 273 6.4.3.2.1.2. The Attribute "supaECAFailStrategy" 65 274 6.4.3.2.2. SUPAECAPolicyRuleComposite Relationships 66 275 6.4.3.2.2.1 The Aggregation "SUPAECAPolicyRules" 66 276 6.4.3.2.2.2. The Association Class 277 "SUPAECAPolicyRuleDetail" .......... 66 278 6.5. SUPAPolicyStatement Subclasses ......................... 66 279 6.5.1. Designing SUPAPolicyStatements Using 280 SUPABooleanClauses ............................... 66 281 6.5.2. The Abstract Class"SUPABooleanClause" ............. 67 282 6.5.2.1. SUPABooleanClause Attributes ................. 68 283 6.5.2.1.1. The Attribute "supaBoolIsNegated" ....... 69 284 6.5.2.1.2. The Attribute "supaPolStmtBindValue" .... 69 285 6.5.2.2. SUPABooleanClause Relationships .............. 69 286 6.5.2.2.1. The Relationship "SUPABooleanClauses" ... 69 287 6.5.2.2.1.1. The Association Class 288 "SUPABooleanClauseDetail" .......... 69 289 6.5.3. SUPABooleanClause Subclasses ...................... 70 290 6.5.3.1. The Abstract Class "SUPABooleanClauseAtomic" . 70 291 6.5.3.2. The Abstract Class 292 "SUPABooleanClauseComposite" ................. 70 293 6.5.3.2.1. SUPABooleanClauseComposite Attributes ... 70 294 6.5.3.2.1.1. The Attribute "supaBoolClauseIsCNF" 71 295 6.6. The Abstract Class "SUPAECAComponent" ............... 71 296 6.6.1. SUPAECAComponent Attributes .................... 71 297 6.6.2. SUPAECAComponent Relationships ................. 71 298 6.6.2.1. The Aggregation "SUPAECAComponentsInTerms" 71 299 6.6.2.1.1. The Association Class 300 "SUPAECAComponentsInTermDetail" ...... 72 302 Table of Contents (continued) 304 6.6.3. SUPAECAComponent Subclasses ....................... 72 305 6.6.3.1. The Concrete Class"SUPAEvent" ................ 72 306 6.6.3.2. The Concrete Class"SUPACondition" ............ 72 307 6.6.3.3. The Concrete Class"SUPAAction" ............... 72 308 7. SUPA Logic Statement Information Model ...................... 73 309 7.1. Overview ............................................... 73 310 7.2. Constructing a SUPAPLStatement ......................... 73 311 7.3. Working With SUPAPLStatements .......................... 73 312 7.4. The Abstract Class "SUPALogicClause" ................... 73 313 7.5. The Abstract Class "SUPAPLStatement" ................... 74 314 7.5.1. SUPAPLStatement Attributes ........................ 74 315 7.5.2. SUPAPLStatement Relationships ..................... 74 316 7.5.3. SUPAPLStatement Subclasses ........................ 75 317 7.5.3.1. The Concrete Class "SUPAPLArgument" ............. 75 318 7.5.3.2. The Concrete Class "SUPAPLPremise" .............. 75 319 7.5.3.3. The Concrete Class "SUPAPLConclusion" ........... 75 320 7.6. Constructing a SUPAFOLStatement ........................ 75 321 7.7. Working With SUPAFOLStatements ......................... 75 322 7.7.1. SUPAFOLStatement Attributes ....................... 75 323 7.7.2. SUPAFOLStatement Relationships .................... 75 324 7.7.3. SUPAFOLStatement Subclasses ....................... 75 325 7.7.3.1. The Concrete Class "SUPAGoalHead" ............... 75 326 7.7.3.2. The Concrete Class "SUPAGoalBody" ............... 75 327 7.8. Combining Different Types of SUPAFOLStatements ......... 75 328 8. Examples .................................................... 76 329 8.1. SUPAECAPolicyRule Examples ............................. 76 330 8.2. SUPALogicStatement Examples ............................ 76 331 8.3. Mixing SUPAECAPolicyRules and SUPALogicStatements ...... 76 332 9. Security Considerations .................................... 76 333 10. IANA Considerations ........................................ 76 334 11. Acknowledgments ............................................ 76 335 12. References ................................................. 76 336 12.1. Normative References .................................. 76 337 12.2. Informative References ............................... 76 338 Authors' Addresses ............................................. 7 340 1. Introduction 342 The Simplified Use Policy Abstractions (SUPA) addresses the needs 343 of operators and application developers to represent multiple types 344 of policy rules using a common structure. This enables policy rules 345 to be defined independent of language, protocol, repository, and 346 the level of abstraction of the content of the policy rule. This 347 common framework currently takes the form of a set of three 348 information model fragments. The SUPA Generic Policy Information 349 Model (GPIM) defines a common set of policy management concepts 350 that are independent of the type of policy rule, while the SUPA 351 ECA Policy Rule Information Model (EPRIM) and SUPA Logic Statement 352 Information Model (LSIM) define information models that are 353 specific to the needs of Event-Condition-Action (ECA) policy rules 354 and statements that are subsets of either Propositional Logic (PL) 355 or First-Order Logic (FOL), respectively. 357 2. Conventions Used in This Document 359 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 360 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 361 this document are to be interpreted as described in [RFC2119]. In 362 this document, these words will appear with that interpretation 363 only when in ALL CAPS. Lower case uses of these words are not to 364 be interpreted as carrying [RFC2119] significance. 366 3. Terminology 368 This section defines acronyms, terms, and symbology used in the 369 rest of this document. 371 3.1. Acronyms 373 CLI Command Line Interface 374 CNF Conjunctive Normal Form 375 DNF Disjunctive Normal Form 376 ECA Event-Condition-Action 377 EPRIM (SUPA) ECA Policy Rule Information Model 378 FOL First Order Logic 379 GPIM (SUPA) Generic Policy Information Model 380 LSIM (SUPA) Logic Statement Information Model 381 NETCONF Network Configuration protocol 382 OAM&P Operations, Administration, Management, and Provisioning 383 OID Object IDentifier 384 PAP Policy Administration Point 385 PDP Policy Decision Point 386 PEP Policy Enforcement Point 387 PIP Policy Information Point 388 PL Propositional Logic 389 PR Policy Repository 390 PXP Policy Execution Point 391 SUPA Simplified Use of Policy Abstractions 392 TMF TeleManagent Forum (TM Forum) 393 UML Unified Modeling Language 394 URI Uniform Resource Identifier 395 YANG A data definition language for use with NETCONF 396 ZOOM Zero-touch Orchestration, Operations, and Management 397 (a TMF project that also works on information models) 399 3.2. Definitions 401 This section defines the terminology that is used in this document. 403 3.2.1. Core Terminology 405 The following subsections define the terms "information model" and 406 "data model". 408 3.2.1.1. Information Model 410 An information model is a representation of concepts of interest 411 to an environment in a form that is independent of data repository, 412 data definition language, query language, implementation language, 413 and protocol. 415 Note: this definition is different than that of [RFC3198]. An 416 information model is defined in [RFC3198] as: "An abstraction and 417 representation of the entities in a managed environment, their 418 properties, attributes, and operations, and the way that they 419 relate to each other. It is independent of any specific repository, 420 software usage, protocol, or platform." The SUPA definition is 421 more specific, and corrects the following ambiguities: 423 o Most information models do not define operations; this is 424 typically implementation-specific and a function of (at least) 425 the language, protocol, and data repository used. 426 o It is unclear what the difference is between the terms 427 "properties" and "attributes" (these are typically synonyms in 428 modeling terminology) 429 o It is unclear what is meant by "software usage". 430 o It is unclear what is meant by "platform". 432 3.2.1.2. Data Model 434 A data model is a representation of concepts of interest to an 435 environment in a form that is dependent on data repository, data 436 definition language, query language, implementation language, and 437 protocol (typically, but not necessarily, all three). 439 Note: this definition is different than that of [RFC3198]. A data 440 model is defined in [RFC3198] as: "A mapping of the contents of an 441 information model into a form that is specific to a particular type 442 of data store or repository." The SUPA definition is more specific. 443 For example, it takes into account differences between two 444 implementations that use the same protocol, implementation 445 language, and data repository, but which have different data 446 definition and/or query protocols. 448 3.2.1.3. Container 450 A container is an object whose instances may contain zero or more 451 additional objects, including container objects. A container 452 provides storage, query, and retrieval of its contained objects 453 in a well-known, organized way. 455 3.2.1.4. PolicyContainer 457 In this document, a PolicyContainer is a special type of container 458 that provides at least the following three functions: 460 1. It uses metadata to define how its content is interpreted 461 2. It separates the content of the policy from the 462 representation of the policy 463 3. It provides a convenient control point for OAMP operations 465 The combination of these three functions enables a PolicyContainer 466 to define the behavior of how its constituent components will be 467 accessed, queried, stored, retrieved, and how they operate. 469 3.2.2. Policy Terminology 471 The following terms define different policy concepts used in the 472 SUPA Generic Policy Information Model (GPIM). Note that the 473 prefix "SUPA" is used for all classes and relationships defined 474 in the GPIM to ensure name uniqueness. Similarly, the prefix 475 "supa" is defined for all SUPA class attributes. 477 3.2.2.1. SUPAPolicy 479 A SUPAPolicy is an abstract class that is a type of 480 PolicyContainer. 482 SUPAPolicy is defined generically as a means to monitor and control 483 the changing and/or maintaining of the state of one or more managed 484 objects [1]. In this context, "manage" means that at least create, 485 read, query, update, and delete functions are supported. 487 3.2.2.2. SUPAPolicyStatement 489 A SUPAPolicyStatement is an abstract class that contains an 490 individual or group of related functions that are used to build 491 different types of policies. This document defines two different 492 types of policies: ECA policy rules and declarative policies. 493 These different types of policies can be used to define a set of 494 actions to take, or declaratively define a goal to be achieved 495 and/or a set of facts to be used. 497 3.2.2.3. SUPAECAPolicyRule 499 An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an 500 abstract class that represents a policy rule as a three-tuple, 501 consisting of an event, a condition, and an action clasue. Each 502 clause MUST be defined by at least one SUPAPolicyStatement. 503 Optionally, the SUPAECAPolicyRule MAY contain one or more 504 SUPAPolicySubjects, one or more SUPAPolicyTargets, and one or 505 more SUPAPolicyMetadata objects. 507 3.2.2.4. SUPALogicStatement 509 A SUPALogicStatement is an abstract class that represents 510 declarative (also called intent-based) policies. A 511 SUPALogicStatement MUST contain at least one SUPAPolicyStatement. 512 Such policies define a goal to be achieved, or a set of actions to 513 take, but do not prescribe how to achieve the goal or execute the 514 actions. This differentiates it from a SUPAECAPolicyRule, which 515 explicitly defines what triggers the evaluation of the 516 SUPAECAPolicyRule, what conditions must be satisfied in order to 517 execute the actions of the SUPAECAPolicyRule, and what actions to 518 execute. 520 3.2.2.5. SUPAMetadata 522 Metadata is, literally, data about data. SUPAMetadata is an 523 abstract class that contains prescriptive and/or descriptive 524 information about the object(s) that it is attached to. While 525 metadata can be attached to any information model element, this 526 document only considers metadata attached to classes and 527 relationships. 529 When defined in an information model, each instance of the 530 SUPAMetadata class MUST have its own aggregation relationship 531 with the set of objects that it applies to. However, a data model 532 MAY map these definitions to a more efficient form (e.g., 533 flattening the object instances into a single object instance). 535 3.2.2.6. SUPAPolicyTarget 537 SUPAPolicyTarget is an abstract class that defines a set of 538 managed objects that may be affected by the actions of a 539 SUPAPolicyStatement. A SUPAPolicyTarget may use one or more 540 mechanisms to identify the set of managed objects that it 541 affects; examples include OIDs and URIs. 543 When defined in an information model, each instance of the 544 SUPAPolicyTarget class MUST have its own aggregation 545 relationship with each SUPAPolicy that uses it. However, a 546 data model MAY map these definitions to a more efficient form 547 (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and 548 SUPAPolicy object instances into a single object instance). 550 3.2.2.7. SUPAPolicySubject 552 SUPAPolicySubject is an abstract class that defines a set of 553 managed objects that authored this SUPAPolicyStatement. This is 554 required for auditability. A SUPAPolicySubject may use one or more 555 mechanisms to identify the set of managed objects that authored it; 556 examples include OIDs and URIs. 558 When defined in an information model, each instance of the 559 SUPAPolicySubject class MUST have its own aggregation relationship 560 with each Policy that uses it. However, a data model MAY map these 561 definitions to a more efficient form (e.g., flattening the 562 PolicySubject, Metadata, and Policy object instances into a single 563 object instance). 565 3.2.3. Modeling Terminology 567 The following terms define different types of relationships used 568 in the information models of the SUPA Generic Policy Information 569 Model (GPIM). 571 3.2.3.1. Inheritance 573 Inheritance makes an entity at a lower level of abstraction (e.g., 574 the subclass) a type of an entity at a higher level of abstraction 575 (e.g., the superclass). Any attributes and relationships that are 576 defined for the superclass are also defined for the subclass. 577 However, a subclass does NOT change the characteristics or behavior 578 of the attributes or relationships of the superclass that it 579 inherits from. Formally, this is called the Liskov Substitution 580 Principle [7]. This principle is one of the key characteristics 581 that is NOT followed in [RFC3060] and [RFC3460]. 583 A subclass MAY add new attributes and relationships that refine 584 the characteristics and/or behavior of it compared to its 585 superclass. 587 3.2.3.2. Relationship 589 A relationship is a generic term that represents how a first set 590 of entities interact with a second set of entities. A recursive 591 relationship sets the first and second entity to the same entity. 592 There are three basic types of relationships, as defined in the 593 subsections below: associations, aggregations, and compositions. 595 3.2.3.3. Association 597 An association represents a generic dependency between a first 598 and a second set of entities. In an information model, an 599 association MAY be represented as a class. 601 3.2.3.4. Aggregation 603 An aggregation is a stronger type (i.e., more restricted 604 semantically) of association, and represents a whole-part 605 dependency between a first and a second set of entities. Three 606 objects are defined by an aggregation: the first entity, the 607 second entity, and a new third entity that represents the 608 combination of the first and second entities. The entity owning 609 the aggregation is referred to as the "aggregate", and the entity 610 that is aggregated is referred to as the "part". In an 611 information model, an aggregation MAY be represented as a class. 613 3.2.3.5. Composition 615 A composition is a stronger type (i.e., more restricted 616 semantically) of aggregation, and represents a whole-part 617 dependency with two important behaviors. First, an instance of the 618 part is included in at most one instance of the aggregate at a 619 time. Second, any action performed on the composite entity (i.e., 620 the aggregate) is propagated to its constituent part objects. For 621 example, if the composite entity is deleted, then all of its 622 constituent part entities are also deleted. This is not true of 623 aggregations or associations - in both, only the entity being 624 deleted is actually removed, and the other entities are unaffected. 625 In an information model, a composition MAY be represented as 626 a class. 628 3.2.3.6. Association Class 630 A relationship may be implemented as an association class. This is 631 used to define the relationship as having its own set of features. 632 More specifically, if the relationship is implemented as an 633 association class, then the attributes of the association class, as 634 well as other relationships that the association class participates 635 in, may be used to define the semantics of the relationship. If the 636 relationship is not implemented as an association class, then no 637 additional semantics (beyond those defined by the type of the 638 relationship) are expressed by the relationship. 640 In an information model, a composition MAY be represented as 641 a class. 643 3.2.3.7. Multiplicity 645 A specification of the range of allowable cardinalities that a set 646 of entities may assume. This is always a pair of ranges, such as 647 1 - 1 or 0..n - 2..5. 649 3.2.3.8. Navigability 651 A relationship may have a restriction on the ability of an object 652 at one end of the relationship to access the object at the other 653 end of the relationship. This document defines two choices: 655 1. Each object is navigable by the other, which is indicated 656 by NOT providing any additional symbology, or 657 2. An object A can navigate to object B, but object B cannot 658 navigate to object A. This is indicated by an open-headed 659 arrow pointing to the object that cannot navigate to the 660 other object. In this example, the arrow would be pointing 661 at object B. 663 3.2.3.9. Abstract Class 665 An abstract class is a class that cannot be directly instantiated. 667 3.2.3.10. Concrete Class 669 A concrete class is a class that can be directly instantiated. 671 3.2.4. Mathematical Logic Terminology 673 This section defines terminology for mathematical logic. 675 3.2.4.1. Predicate 677 A predicate is a Boolean-valued function (i.e., a function whose 678 values are interpreted as either TRUE or FALSE, depending on the 679 values of its variables). 681 3.2.4.2. Logic Operators 683 A logical connective is a symbol or word that defines how to 684 connect two or more sentences in a language. 686 3.2.4.2.1. Propositional Logic Connectives 688 There are five propositional logic connectives, defined as follows: 690 o Negation, or a logical NOT operator, is an operation that, 691 when applied to a proposition, produces a new proposition 692 "not p", which has the opposite truth value of p. 693 o Conjunction, or a logical AND operator, is an operation on two 694 logical values that produces a value of TRUE if and only if 695 both of its operands are TRUE. 696 o Disjunction, or a logical OR operator, is an operation on two 697 logical values that produces a value of FALSE if and only if 698 both of its operands are FALSE. 699 o Implication, or the conditional operator, is used to form 700 statements of the form "if is TRUE, then 701 is also TRUE (i.e., this statement is FALSE 702 only when A is TRUE and B is FALSE). 703 o Bi-implication, or the bi-conditional operator, is used to 704 form statements of the form " is TRUE if and 705 only if is TRUE (i.e., this statement is TRUE 706 if and only if both propositions are FALSE or if both 707 propositions are TRUE). 709 3.2.4.2.2. First Order Logic Quantifiers 711 This document defines two types of quantifiers for First Order 712 Logic statements. 714 Quantification specifies the number of objects that satisfies a 715 formula. This document uses two such quantifiers, which are 716 defined as follows: 718 o Universal quantification asserts that a predicate within the 719 scope of this operator is TRUE of every value of a variable of 720 the predicate. It is commonly interpreted as "for all". 721 o Existential quantification asserts that a predicate within the 722 scope of this operator is TRUE for at least one value of a 723 variable of the predicate. It is commonly interpreted as 724 "there exists, "there is at least one", or "for some". 726 3.2.4.3. Propositional Logic 728 Propositional Logic (PL) may be simply defined as a language 729 consisting of a set of statements; the value of each statement is 730 either TRUE or FALSE. More formally, a (propositional) Argument 731 consists of a sequence of Premises and a Conclusion. An Argument is 732 valid if the Conclusion is TRUE whenever all Premises are TRUE. 734 PL may be thought of as a set of declarative propositions. 736 3.2.4.4. First-Order Logic 738 First-Order Logic (FOL) may be simply defined as a language 739 consisting of a set of statements; each statement is a predicate. 741 A predicate is a Boolean-valued function (i.e., the value of the 742 function evaluates to either TRUE or FALSE, depending on the value 743 of its variables). Predicates can also be compared. 745 FOL uses quantified variables. The universal quantifier and/or the 746 existential quantifier can be used to define what values can be 747 instantiated by the predicated variables. 749 3.3. Symbology 751 The following symbology is used in this document: 753 3.3.1. Inheritance 755 Inheritance: a subclass inherits the attributes and relationships 756 of its superclass, as shown below: 758 +------------+ 759 | Superclass | 760 +------+-----+ 761 / \ 762 I 763 I 764 I 765 +------+-----+ 766 | Subclass | 767 +------------+ 769 3.3.2. Association 771 Association: Class B depends on Class A, as shown below: 773 +---------+ +---------+ 774 +---------+ +---------+ | | \| | 775 | Class A |------| Class B | | Class A |------| Class B | 776 +---------+ +---------+ | | /| | 777 +---------+ +---------+ 779 association with no association with 780 navigability restrictions navigability restrictions 782 3.3.3. Aggregation 784 Aggregation: Class B is the part, Class A is the aggregate, 785 as shown below: 787 +---------+ +---------+ +---------+ 788 | |/ \ +---------+ | |/ \ \| | 789 | Class A | A ---| Class B | | Class A | A ------| Class B | 790 | |\ / +---------+ | |\ / /| | 791 +---------+ +---------+ +---------+ 793 aggregation with no aggregation with 794 navigability restrictions navigability restrictions 796 3.3.4. Composition 798 Composition: Class B is the part, Class A is the composite, 799 as shown below: 801 +---------+ +---------+ +---------+ 802 | |/ \ +---------+ | |/ \ \| | 803 | Class A | C ---| Class B | | Class A | C ------| Class B | 804 | |\ / +---------+ | |\ / /| | 805 +---------+ +---------+ +---------+ 807 composition with no composition with 808 navigability restrictions navigability restrictions 810 3.3.5. Association Class 812 Association Class: Class C is the association class implementing 813 the relationship D between classes A and B 815 +---------+ +---------+ 816 | Class A |----+-----| Class B | 817 +---------+ ^ +---------+ 818 | 819 | 820 +----------+----------+ 821 | Association Class C | 822 +---------------------+ 824 3.3.6. Logical Connectives 826 The following defines a mapping between the typical mathematical 827 symbols used for logical connectives (most of which are in 828 extended ASCII) and the symbols that will be used in this document. 830 Connective ASCII CODE UNICODE Code Meaning 831 Negation 172 U+00AC "NOT" 832 Conjunction 8743 U+2227 "AND" 833 Disjunction 8744 U+2228 "OR" 834 Implication 8658 U+21D2 "IMPLIES" 835 Bi-implication 8660 U+21D4 "IF AND ONLY IF" 837 3.3.7. Quantifiers 839 The following defines a mapping between the typical mathematical 840 symbols used for quantifiers and the symbols that will be used in 841 this document. 843 Quantifier ASCII Code Unicode Code Symbol Used 844 Universal 8704 U+2200 "FOR ALL" 845 Existential 8707 U+2203 "THERE EXISTS" 847 4. Policy Abstraction Architecture 849 This section describes the motivation for the policy abstractions 850 that are used in SUPA. The following abstractions are provided: 852 o The GPIM defines a technology-neutral information model that 853 can express the concept of Policy. 854 o This version of this document restricts the expression of 855 Policy to 856 o a set of event-condition-action tuples 857 o a set of PL or FOL statements 858 o a combination of ECA rules and PL or FOL statements. 859 o Since these representations are very different in syntax and 860 content, the content of a Policy is abstracted from its 861 representation: 862 o SUPAECAPolicyRules and SUPALogicStatements are each types 863 of SUPAPolicies 864 o SUPAECAPolicyRules and SUPALogicStatements are both 865 constructed from SUPAPolicyStatements 866 o A SUPAPolicy MAY use SUPAECAPolicyRules and/or 867 SUPALogicStatements 868 o A SUPAPolicy consists of one or more SUPAPolicyStatements, 869 and optionally may specify one or more SUPAPolicyTarget, 870 SUPAPolicySubject, and SUPAPolicyMetadata objects 871 o A SUPAPolicyStatement has three subclasses: 872 o a SUPABooleanClause for building SUPAECAPolicyRules from 873 reusable objects 874 o a SUPALogicClause for building SUPALogicStatements from 875 reusable objects 876 o a SUPAENcodedClause for using attributes instead of 877 objects to construct a SUPAECAPolicyRule or a 878 SUPALogicStatement 879 o A SUPAPolicy MUST contain at least one SUPAPolicyStatement. 880 o A SUPAECAPolicyRule defines the set of events and conditions 881 that are responsible for executing its actions; it MUST have 882 an event clause, a condition clause, and an action clause. 883 o A SUPALogicStatement expresses facts that it believes to be 884 true without defining how those facts are computed, and 885 provides an efficient query mechanism for retrieving facts. 886 Each SUPAPolicyStatement MUST be expressed as a function-free 887 Horn clause; there are a number of additional restrictions 888 that are covered in Section 7. 889 o SUPAMetadata MAY be defined for any type of 890 SUPAPolicyStatement (as well as for individual objects that 891 make up a SUPAPolicyStatement). 892 o SUPAMetadata MAY be prescriptive and/or descriptive in nature. 893 o A SUPAPolicyTarget is a set of managed objects that the 894 actions of the SUPAPolicy are applied to. 895 o A SUPAPolicySubject is a set of managed objects that authored 896 the SUPAPolicy. 898 4.1. Motivation 900 The power of policy management is its applicability to many 901 different types of systems. There are many different actors that 902 can use a policy management system, including end-users, operators, 903 application developers, and administrators. Each of these 904 constituencies have different concepts and skills, and use 905 different terminology. For example, an operator may want to express 906 an operational rule that states that only Platinum and Gold users 907 can use streaming multimedia applications. As a second example, a 908 network administrator may want to define a more concrete policy 909 rule that looks at the number of dropped packets and, if that 910 number exceeds a programmable threshold, changes the queuing and 911 dropping algorithms used. 913 SUPA may be used to define other types of policies, such as for 914 systems and operations management; an example is: "All routers and 915 switches must have password login disabled". See section 3 of [8] 916 for additional declarative and ECA policy examples. 918 All of the above examples are commonly referred to as "policy 919 rules", but they take very different forms, since they are at very 920 different levels of abstraction and typically authored by 921 different actors. The first was very abstract, and did not contain 922 any technology-specific terms, while the second was more concrete, 923 and likely used technical terms of a general (e.g., IP address 924 range, port numbers) as well as a vendor-specific nature (e.g., 925 specific queuing, dropping, and/or scheduling algorithms 926 implemented in a particular device). The third restricted the type 927 of login that was permissible for certain types of devices in the 928 environment. 930 Note that the first two policy rules could directly affect each 931 other. For example, Gold and Platinum users might need different 932 device configurations to give the proper QoS markings to their 933 streaming multimedia traffic. This is very difficult to do if a 934 common policy model does not exist. 936 More importantly, the users of these two policies likely have 937 different job responsibilities. They may have no idea of the 938 concepts used in each policy. Yet, their policies need to interact 939 in order for the business to provide the desired service. This 940 again underscores the need for a common policy framework. 942 Certain types of policy rules (e.g., ECA) may express actions, or 943 other types of operations, that contradict each other. SUPA 944 provides a rich object model that can be used to support language 945 definitions that can find and resolve such problems. 947 4.2. SUPA Approach 949 The purpose of the SUPA Generic Policy Information Model (GPIM) is 950 to define a common framework for expressing policies at different 951 levels of abstraction. SUPA uses the GPIM as a common vocabulary 952 for representing policy concepts that are independent of language, 953 protocol, repository, and level of abstraction. This enables 954 different actors to author and use policies at different levels of 955 abstraction. This forms a policy continuum [1] [2], where more 956 abstract policies can be translated into more concrete policies, 957 and vice-versa. 959 Most systems define the notion of a policy as a single entity. 960 This assumes that all users of policy have the same terminology, 961 and use policy at the same level of abstraction. This is rarely, 962 if ever, true in modern systems. The policy continuum defines a 963 set of views (much like RM-ODP's viewpoints [9]) that are each 964 optimized for a user playing a specific role. SUPA defines the 965 GPIM as a standard vocabulary and set of concepts that enable 966 different actors to use different formulations of policy. This 967 corresponds to the different levels in the policy continuum, and 968 as such, can make use of previous experience in this area. 970 It may be necessary to translate a Policy from a general to a more 971 specific form (while keeping the abstraction level the same). For 972 example, the declarative policy "Every network attached to a VM 973 must be a private network owned by someone in the same group as 974 the owner of the VM" may be translated to more formal form (e.g., 975 Datalog (as in OpenStack Congress) or a set of 976 SUPALogicStatements). It may also be necessary to translate a 977 Policy to a different level of abstraction. For example, the 978 previous Policy may need to be translated to a form that network 979 devices understand. This requires a common framework for 980 expressing policies that is independent of the level of 981 abstraction that a Policy uses. 983 4.3. SUPA Generic Policy Information Model Overview 985 Figure 1 illustrates the approach for representing policy rules 986 in SUPA. The top two layers are defined in this document; the 987 bottom layer (Data Models) are defined in separate documents. 988 Conceptually, the GPIM defines a set of objects that define the 989 key elements of a Policy independent of how it is represented or 990 its content. As will be shown, there is a significant difference 991 between SUPAECAPolicyRules (see Section 6) and SUPALogicStatements 992 (see Section 7). In principle, other types of SUPAPolicies could 993 be defined, but the current charter is restricted to using these 994 two types of SUPAPolicies as exemplars. 996 +----------------------------------------------+ 997 | SUPA Generic Policy Information Model (GPIM) | 998 +----------------------+-----------------------+ 999 / \ 1000 | 1001 | 1002 +-----------------+--------------+ 1003 | | 1004 | | 1005 +-----------+---------------+ +-------------+------------+ 1006 | SUPAECAPolicyRule | | SUPA Logic Statement | 1007 | Information Model (EPRIM) | | Information Model (LSIM) | 1008 +-----------+---------------+ +-------------+------------+ 1009 / \ / \ 1010 | | 1011 | | 1012 +-----------+-----------+ +-----------+------------+ 1013 | ECAPolicyRule | | Logic Statement | 1014 | Data Model | | Data Model | 1015 +-----------------------+ +------------------------+ 1017 Figure 1: Overview of SUPA Policy Rule Abstractions 1019 The GPIM defines the following concepts: 1021 o SUPAPolicy: the root of the SPGIM model 1022 o SUPAPolicyAtomic: a Policy that can be used in a stand-alone 1023 manner 1024 o SUPAPolicyComposite: used to build hierarchies of Policies 1025 o SUPAPolicyStatement: used to define the content of a SUPAPolicy 1026 o SUPAPolicyTerm: used to define variables, operators, and 1027 values in a SUPAPolicyStatement 1028 o SUPAPolicySubject: the author of a SUPAPolicy 1029 o SUPAPolicyTarget: the managed object that a SUPAPolicy 1030 monitors and/or controls the state of 1031 o SUPAPolicyMetadata: specifies descriptive and/or prescriptive 1032 information about a SUPAPolicy object 1034 A SUPAPolicy object serves as a single root of the SUPA system 1035 (i.e., all other classes in the model are subclasses of the 1036 SUPAPolicy class). This simplifes code generation and reusability. 1037 Note that this is NOT true of either [4] or [6]; it is true of [2]. 1039 SUPA Policies are defined as either a stand-alone or a hierarchy 1040 of PolicyContainers. A PolicyContainer specifies the structure, 1041 content, and optionally, subject, target, and metadata information 1042 for the Policy. 1044 A SUPAPolicy takes one of two forms: (1) an ECA Policy, and/or 1045 (2) a declarative set of statements. The GPIM enables both types 1046 of policies to be combined; this is also true of [2] and [5]. 1047 However, this is not true of [4] and [6], since neither define 1048 declarative policies (additional reasons are beyond the scope of 1049 this document). 1051 The GPIM design enables a Policy of one type to invoke Policies 1052 of the other type. For example, a declarative policy may directly 1053 or indirectly invoke one or more ECA policies. Since declarative 1054 policies are at a higher level of abstraction, this is the typical 1055 case, though it is possible for the reverse to occur. For example, 1056 an ECA policy could invoke a declarative policy as one of its 1057 actions if it is more appropriate to specify a generic, as opposed 1058 to a prescriptive, course of action. This is also true of [2] and 1059 [5]; however, this is not true of [4] and [6], since neither 1060 define declarative policies (additional reasons are beyond the 1061 scope of this document). 1063 Both a SUPAECAPolicyRule and a SUPALogicalStatement are made up of 1064 one or more SUPAPolicyStatements, which define the content of the 1065 Policy. Three types of SUPAPolicyStatements are available; one is 1066 generic, and can be used by any type of Policy, while the other 1067 two are specific to an ECA or a declarative Policy, respectively. 1068 The generic SUPAPolicyStatement, called SUPAEncodedClause, encodes 1069 the policy as an attribute. In contrast, the two specific types of 1070 SUPAPolicyStatements (SUPABooleanClause and SUPALogicClause, which 1071 are used for ECA and declarative policies, respectively), typically 1072 are made up of (reusable) SUPAPolicy objects. All three may thus be 1073 constructed at runtime by a machine. This is also true of [2] and 1074 [5]; however, this is not true of [4] and [6], since both lack 1075 the abstraction of a common PolicyStatement. 1077 A SUPAPolicyStatement may be made up of SUPAPolicyTerms, which 1078 enables a clause to be defined in a canonical {variable, operator, 1079 value} form. In addition, specific objects for constructing ECA 1080 Policies and declarative Policies are also provided. This is 1081 provided to enable machine-driven construction of policies. 1083 This set of classes enables each different types of Policies to be 1084 defined by an information model that refines the generic concepts 1085 of the GPIM as described above. For example, a SUPAECAPolicyRule, 1086 as well as a SUPALogicStatement, are both subclasses of the 1087 SUPAPolicyAtomic class. Therefore, both can be used as part of a 1088 hierarchy of Policies or in a stand-alone manner. As another 1089 examples, a SUPALogicClause and a SUPABooleanClause are both 1090 subclasses of SUPAPolicyStatement, and are used to create 1091 SUPALogicStatements and SUPAECAPolicyRules, respectively. 1093 4.4. Structure of SUPA Policies 1095 This section describes the overall design of the GPIM. 1097 4.4.1. ECA Policy Rule Structure 1099 A SUPAECAPolicyRule is a statement that consists of an event 1100 clause, a condition clause, and an action clause. This type of 1101 Policy explicitly defines the current and desired states of the 1102 system being managed. Conceptually, it is represented as follows: 1104 +------------------+ +---------------------+ 1105 | SUPAPolicyAtomic | | SUPAPolicyStatement | 1106 +---------+--------+ +----------+----------+ 1107 / \ / \ 1108 I I 1109 I I 1110 I I 1111 I +----------------+------------------+ 1112 +------------+------------+ | SUPABooleanClause or | 1113 | SUPAECAPolicyRule | | SUPAEncodedClause | 1114 +------+-------+-------+--+ +------+-----------+-----------+----+ 1115 0..1/ \ 0..1/ \ 0..1/ \ / \ / \ / \ 1116 A A A I I I 1117 \ / \ / \ / I I I 1118 | | | +----+---+ I I 1119 | | | | Event | I I 1120 | | | | Clause | +-----+-----+ I 1121 | | | +------+-+ | Condition | I 1122 | | | 1..n/ \ | Clause | +---+----+ 1123 | | | | +-------+---+ | Action | 1124 | | | | 1..n/ \ | Clause | 1125 | | | | | +-----+--+ 1126 | | | | | 1..n/ \ 1127 | | +--------------+ | | 1128 | | HasSUPAEvents | | 1129 | | | | 1130 | +----------------------------------+ | 1131 | HasSUPAConditions | 1132 | | 1133 +------------------------------------------------------+ 1134 HasSUPAActions 1136 Figure 2: Overview of SUPA Policy Rule Abstractions 1138 Note that the event, condition, and action clauses may be defined 1139 by using SUPABooleanClauses or SUPAEncodedClauses. See section 6.5 1140 for the former and 5.5 (especially 5.5.2.1) for the latter. 1142 4.4.2. Logical Statement Structure 1144 A SUPALogicStatement is either a set of PL or FOL statements. 1145 These are called SUPAPLStatement and SUPAFOLStatement, 1146 respectively. 1148 A SUPAPLStatement is a set of propositions that form a (single) 1149 conclusion. A proposition is either TRUE or FALSE. A proposition 1150 be created from simpler propositions combined using Propositional 1151 Logic Connectives (see Section Propositions (see Section 1152 3.2.4.2.1.). It may be conceptualized as follows: 1154 +---------------------+ 1155 | SUPAPLogicStatement | 1156 +-----------+---------+ 1157 / \ 1158 I 1159 I 1160 I 1161 +--------+--------+ 1162 | SUPAPLStatement | 1163 +--------+--------+ 1164 / \ 1165 I 1166 I 1167 +------------------+--+--------------------+ 1168 I I I 1169 I I I 1170 I I I 1171 +-------+-------+ +---------+--------+ +--------+-------+ 1172 | SUPAPLPremise | | SUPAPLConclusion | | SUPAPLArgument | 1173 +---------+-----+ +----------+-------+ +-----+--------+-+ 1174 1..n / \ 1 / \ 0..1/ \ 0..1/ \ 1175 | | A A 1176 | | | | 1177 | | | | 1178 | +----------------+ | 1179 | HasSUPAPLConclusion | 1180 | | 1181 +----------------------------------------------+ 1182 HasSUPAPLPremises 1184 Figure 3: Overview of SUPA Propositional Logic Abstractions 1186 As shown in Figure 4, a SUPAPLArgument consists of a set of one 1187 or more SUPAPLPremises and a single SUPAPLConclusion. The 1188 multiplicity of the two aggregations is 0..1 on the aggregate 1189 side to enable SUPAPLPremises and SUPAPLConclusions to be created 1190 and stored indepedent of being used in a SUPAPLArgument. 1192 In PL, each possible atomic fact requires a separate propositional 1193 symbol. This can lead to a large amount of premises required to 1194 form a conclusion. 1196 FOL provides a richer knowledge representation by using: 1198 o objects (i.e., terms), which define individual entities 1199 o properties (i.e., unary predicates on terms), which 1200 distinguishes objects from each other 1201 o relations (i.e., n-ary predicates on terms), which define 1202 facts among a set of objects, and 1203 o functions (i.e., the mapping from one set of terms to another 1204 set of terms). 1206 FOL may be conceptualized as follows: 1208 +---------------------+ 1209 | SUPAPLogicStatement | 1210 +-----------+---------+ 1211 / \ 1212 I 1213 I 1214 I 1215 +---------+--------+ 1216 | SUPAFOLStatement | 1217 +---------+--------+ 1218 / \ 1219 I 1220 I 1221 I 1222 +--------------+------------+ 1223 I I 1224 I I 1225 I I 1226 +-------+------+ +-------+------+ 1227 | SUPAGoalBody | | SUPAGoalHead | 1228 +---------+----+ +-------+------+ 1229 1..n / \ 0..1/ \ 1230 | A 1231 | | 1232 | | 1233 +-------------------------+ 1234 HasSUPAGoalBody 1236 Figure 4: Overview of SUPA First Order Logic Abstractions 1238 FOL Syntax may be described using the following grammar: 1240 Sentence 1241 : AtomicSentence 1242 | Sentence Connective Sentence 1243 | (Quantifier Variable)+ Sentence 1244 | 'NOT' Sentence 1245 | function '(' Sentence ')' 1246 ; 1248 4.5. GPIM Assumptions 1250 Most policy models (e.g., [2], [4], [5], and [6]) are built as part 1251 of an overarching model. SUPA DOES NOT assume that it is the "root 1252 class of everything". Rather, the SUPA information model is built 1253 as a single inheritance model fragment to accommodate inserting the 1254 SUPA model into another model (e.g., the root of the SUPA model 1255 becomes a subclass of the other model). This is shown in Figure 5. 1257 +------------------------------------------+ 1258 | Root Class of an Existing Model | 1259 +--------------------+---------------------+ 1260 / \ 1261 I 1262 I 1263 I 1264 +-----------------+--------------+ 1265 I I 1266 I I 1267 I I 1268 +-----------+-----------+ +------------+------------+ 1269 | A Subclass of the | | Another Subclass of the | 1270 | Existing Model | | Existing Model | 1271 +-----------------------+ +------------+------------+ 1272 / \ 1273 I 1274 I 1275 I 1276 +-----------+------------+ 1277 | SUPA Class Hierarchy | 1278 | (GPIM plus EPRIM | 1279 | and/or LSIM) | 1280 +------------------------+ 1282 Figure 5: Integrating SUPA into an Existing Model 1284 4.6. Scope of Previous Work 1286 Insert intro paragraph and reference SUPA Gap Analysis [6]. Some 1287 salient points on previous policy models: 1289 o [RFC3060] and [RFC3460] only define a policy rule that 1290 consists of a condition clause and an action clause; it does 1291 not define an ECA policy rule, nor does it define a 1292 LogicStatement 1293 o [4] is more elaborate than [RFC3060] and [RFC3460], but 1294 suffers from the same limitations 1295 o [5] defines four types of policies (i.e., ECA, Goal, 1296 UtilityFunction, and Promise), but does not have the detail 1297 defined in this document 1299 Rest to be finished. Sections will include: 1301 o Description of, and problems with, [RFC3060] 1302 o Description of, and problems with, [RFC3460] 1303 o Should this section also talk about CIM or SID? I personally 1304 think that this should be in the gap analysis... 1306 5. GPIM Model 1307 This section defines the classes and relationships of the GPIM. 1309 5.1. Overview 1310 The overall class definition is shown in Figure 6. SUPAPolicy is 1311 the root of the SUPA class hierarchy. For implementations, it is 1312 assumed that SUPAPolicy is subclassed from a class from another 1313 model. In Figure 6, indentation represents subclassing. 1315 (Class of another model that SUPA is integrating into) 1316 | 1317 +---SUPAPolicy (see Section 5.2) 1318 | 1319 +---SUPAPolicyAtomic (see Section 5.3) 1320 | 1321 +---SUPAPolicyComposite (see Section 5.4) 1322 | 1323 +---SUPAPolicyStatement (see Section 5.5) 1324 | 1325 +---SUPAPolicySubject (see Section 5.6) 1326 | 1327 +---SUPAPolicyTarget (see Section 5.7) 1328 | 1329 +---SUPAPolicyTerm (see Section 5.8) 1330 | 1331 +---SUPAPolicyMetadata (see Section 5.9) 1333 Figure 6: Main Classes of the GPIM 1335 The following subsections define the classes of the GPIM. If a 1336 class has attributes, those attributes are also defined. 1337 Relationships are defined according to the class that is the 1338 "owner", or primary actor, participating in the relationship. 1340 Classes, attributes, and relationships that are marked as 1341 "mandatory" MUST be part of a conformant implementation. Classes, 1342 attributes, and relationships that are marked as "optional" 1343 SHOULD be part of a conformant implementation. 1345 5.2. The Abstract Class "SUPAPolicy" 1347 This is a mandatory abstract class. This class is the root of the 1348 SUPA class hierarchy. It defines the common attributes and 1349 relationships that all SUPA subclasses inherit. SUPAPolicy was 1350 abstracted from DEN-ng [2], and a version of this class is in the 1351 process of being added to the policy framework defined in [5]. 1353 A SUPAPolicy takes the form of an individual policy or a set of 1354 policies. The former is defined by an instance of a concrete 1355 subclass of the SUPAPolicyAtomic class. The latter consists of a 1356 set of PolicyContainers; each PolicyContainer is an instance of a 1357 SUPAPolicyComposite (or a subclass of it). Each SupaPolicyComposite 1358 can have zero or more instances of a concrete subclass of the 1359 SUPAPolicyAtomic class. 1361 In this approach, a SUPAPolicyAtomic class is the superclass of 1362 SUPAECAPolicyRule and SUPALogicStatement. These two classes define 1363 the type of policy that is being defined. A SUPAPolicyComposite is 1364 a PolicyContainer with SUPAMetadata attached. Each PolicyContainer 1365 forms its own containment hierarchy, and SUPAMetadata can be used 1366 to describe and/or prescribe how policies behave within each 1367 PolicyContainer. 1369 Each SUPAPolicyAtomic object (or a subclass of it) MUST have at 1370 least one SUPAPolicyStatement that is used to define the content 1371 of the policy. Some types of policies, such as an ECA policy rule, 1372 MUST have at least three SUPAPolicyStatements, one each to define 1373 its event, condition, and action clauses. SUPALogicStatements 1374 typically have multiple SUPAPolicyStatements. 1376 A SUPAPolicy MAY be qualified (i.e., may aggregate these objects 1377 to more completely specify the behavior of the SUPAPolicy) by a 1378 set of zero or more SUPAPolicySubjects, SUPAPolicyTargets, and/or 1379 SUPAPolicyMetadata objects. Note that these three classes are 1380 defined as abstract, in order to simplify mapping to, and 1381 optimization of, data models. When defined in an information model, 1382 the SUPAPolicyAtomic and SUPAPolicyComposite classes MUST have 1383 separate aggregation relationships with the SUPAPolicySubject and 1384 SUPAPolicyTarget objects (or their subclasses), if these objects 1385 are defined. Any subclass of SUPAPolicy that wants to use metadata 1386 MUST have one or more separate aggregation relationships with a 1387 SUPAPolicyMetadata class (or its subclasses). When implemented in 1388 a data model, the set of SUPAPolicyStatement, SUPAPolicyTarget, 1389 SUPAPolicySubject, and SUPAPolicyMetadata object instances SHOULD 1390 all be part of a single PolicyContainer object. They MAY be 1391 translated to a more efficient form (e.g., flattening the objects 1392 that are participating in the above relationships into a single 1393 object instance). 1395 Figure 7 shows the SUPAPolicy class, and two of its subclasses 1396 (SUPAPolicyAtomic and SUPAPolicyComposite). This is an 1397 implementation of the composite pattern [3], which enables a 1398 SUPAPolicy to be made up of a stand-alone object (an instance of a 1399 SUPAPolicyAtomic class) or a hierarchy of objects (i.e., instances 1400 of one or more SUPAPolicyAtomic and SUPAPolicyComposite classes). 1401 The use of this software pattern enables SUPA Policies to be 1402 designed as individual objects and/or hierarchies of objects. 1404 +-------------------------------+ 1405 | Parent Class of another Model | 1406 +--------------+----------------+ 1407 / \ 1408 +---------------------+ I 1409 | HasSUPAPolicyDetail | I 1410 +-----+---------------+ I 1411 ^ I 1412 | 1..n +---------------+----------------+ 1413 | \| | 1414 +----+--------+ SUPAPolicy | 1415 | /| | 1416 | +---------------+----------------+ 1417 | / \ 1418 | I 1419 | HasSUPAPolicies I 1420 | I 1421 | I 1422 | +-----------+----------+ 1423 | | | 1424 | | | 1425 | 0..1 +----------+----------+ +---------+--------+ 1426 | / \| | | | 1427 +--- A + SUPAPolicyComposite | | SUPAPolicyAtomic | 1428 \ /| | | | 1429 +---------------------+ +------------------+ 1431 Figure 7: The SUPAPolicy Class Hierarchy 1433 Note that a SUPAPolicy, as well as a SUPAPolicyAtomic and a 1434 SUPAPolicyComposite, are all PolicyContainer objects. SUPAPolicy 1435 was abstracted from DEN-ng [2], and a version of this class is in 1436 the process of being added to the policy framework defined in the 1437 TM Forum ZOOM model [5]. 1439 In figure 7: 1441 o Both SUPAPolicyComposite and SUPAPolicyAtomic inherit from 1442 SUPAPolicy 1443 o The diamond with an enclosed "A" represents an aggregation 1444 (see Section 3.2.3.4) 1445 o The HasSUPAPolicies aggregation is implemented as an 1446 association class (see Section 3.2.3.6) 1447 o The multiplicity of the HasSUPAPolicies aggregation is 1448 0..1 - 1..n (zero or one SUPAPolicyComposite object instances 1449 can aggregate one or more SUPAPolicy object instances, see 1450 Section 3.2.3.7) 1451 o The arrow pointing at SUPAPolicy restricts the navigability 1452 of this aggregation (see Section 3.2.3.8) 1454 5.2.1. SUPAPolicy Attributes 1456 This section defines the attributes of the SUPAPolicy class. These 1457 attributes are inherited by all subclasses of the SUPAPolicy class. 1459 5.2.1.1. The Attribute "supaObjectIDContent" 1461 This is a mandatory attribute that represents part of the object 1462 identifier of an instance of this class. It is a string attribute, 1463 and defines the content of the object identifier. It works with 1464 another class attribute, called supaObjectIDFormat, which defines 1465 how to interpret this attribute. These two attributes form a tuple, 1466 and together enable a machine to understand the syntax and value of 1467 an object identifier for the object instance of this class. This is 1468 based on the DEN-ng class design [2]. 1470 One of the goals of SUPA is to be able to generate different data 1471 models that support different types of protocols and repositories. 1472 This means that the notion of an object ID must be generic. In this 1473 way, different naming schemes, such as those depending on URIs, 1474 FQDNs, primary key - foreign key relationships, and UUIDs can all 1475 be accommodated. 1477 5.2.1.2. The Attribute "supaObjectIDFormat" 1479 This is a mandatory attribute that represents part of the object 1480 identifier of an instance of this class. It is a string attribute, 1481 and defines the format of the object identifier. It works with 1482 another class attribute, called supaObjectIDContent, which defines 1483 the content of the object ID. These two attributes form a tuple, 1484 and together enable a machine to understand the syntax and value 1485 of an object identifier for the object instance of this class. 1486 This is based on the DEN-ng class design [2]. 1488 5.2.1.3. The Attribute "supaPolicyDescription" 1490 This is an optional string attribute that defines a free-form 1491 textual description of this object. 1493 5.2.1.4. The Attribute "supaPolicyName" 1495 This is an optional string attribute that defines the name of this 1496 Policy. This enables any existing generic naming attribute to be 1497 used for generic naming, while allowing this attribute to be used 1498 to name Policy entities in a common manner. Note that this is NOT 1499 the same as the commonName attribute of the Policy class defined 1500 in RFC3060 [RFC3060], as that attribute is intended to be used 1501 with just X.500 cn attributes. 1503 5.2.2. SUPAPolicy Relationships 1505 This section defines the relationships of the SUPAPolicy class. 1507 5.2.2.1. The Relationship "SUPAPolicyMetadata" 1509 This is a mandatory aggregation that defines the set of 1510 SUPAPolicyMetadata that are aggregated by this particular 1511 SUPAPolicy object. The multiplicity of this relationship is defined 1512 as 0..1 on the aggregate (SUPAPolicy) side, and 0..n on the part 1513 (SUPAPolicyMetadata) side. This means that this relationship is 1514 optional, but if it is instantiated, then one or more SUPAPolicy 1515 objects are contained in this particular SUPAPolicyComposite 1516 object. The semantics of this aggregation are implemented using 1517 the SUPAPolicyMetadataDetail association class. 1519 5.2.2.2. The Association Class "SUPAPolicyMetadataDetail" 1521 This is a mandatory concrete association class that defines the 1522 semantics of the SUPAPolicyMetadata aggregation. This enables the 1523 attributes and relationships of the SUPAPolicyMetadataDetail class 1524 to be used to constrain which SUPAPolicyMetadata objects can be 1525 aggregated by this particular SUPAPolicy object instance. 1527 Attributes will be added to this class at a later time. 1529 5.3. The Abstract Class "SUPAPolicyAtomic" 1531 This is a mandatory abstract class. This class is a type of 1532 PolicyContainer. SUPAPolicyAtomic was abstracted from DEN-ng [2], 1533 and a version of this class is in the process of being added to 1534 the policy framework defined in the TM Forum ZOOM model [5]. 1536 A SUPAPolicyAtomic class represents a SUPA Policy that can operate 1537 as a single, stand-alone, manageable object. Put another way, a 1538 SUPAPolicyAtomic object can NOT be modeled as a set of hierarchical 1539 SUPAPolicy objects; if this functionality is required, then a 1540 SUPAPolicyComposite object must be used. 1542 The SUPAPolicyAtomic class is the superclass for the different 1543 types of SUPA Policies that are defined. In this release, both a 1544 SUPAECAPolicyRule (see Section 6) as well as a SUPALogicStatement 1545 (see Section 7) are defined as its subclasses. 1547 5.3.1. SUPAPolicyAtomic Attributes 1549 This section defines the attributes of the SUPAPolicyAtomic class. 1551 Care must be taken in adding attributes to this class, because the 1552 behavior of SUPALogicStatements is very different than the behavior 1553 of SUPAECAPolicyRules. 1555 5.3.1.1. The Attribute "supaPolicyDeployStatus" 1557 This is an optional attribute, which is an enumerated, 1558 non-negative integer. It defines the current deployment status of 1559 this SUPAECAPolicyRule. Both operational and test mode values are 1560 included in its definition. Values include: 1562 0: undefined 1563 1: deployed and enabled 1564 2: deployed and in test 1565 3: deployed but not enabled 1566 4: ready to be deployed 1567 5: not deployed 1569 5.3.1.2. The Attribute "supaPolicyExecStatus" 1571 This is an optional attribute, which is an enumerated, 1572 non-negative integer that defines the current execution status of 1573 this SUPAECAPolicyRule. Both operational and test mode values are 1574 included in its definition. Values include: 1576 0: undefined 1577 1: executed and SUCEEDED (operational mode) 1578 2: executed and FAILED (operational mode) 1579 3: currently executing (operational mode) 1580 4: executed and SUCEEDED (test mode) 1581 5: executed and FAILED (test mode) 1582 6: currently executing (test mode) 1584 5.3.2. SUPAPolicyAtomic Relationships 1586 This section defines the relationships of the SUPAPolicyAtomic 1587 class. 1589 5.3.2.1. The Aggregation "SUPAPAHasPolicyStmts" 1591 This is a mandatory aggregation that defines the set of 1592 SUPAPolicyStatements that MUST be aggregated by this particular 1593 SUPAPolicyAtomic object. The multiplicity of the aggregation is 1594 0.n on the aggregate (SUPAPolicyAtomic) side, and 1..n on the part 1595 (SUPAPolicyStatement) side. 1597 The "0..n" part of the multiplicity enables SUPAPolicyStatements to 1598 be stored in a repository for later use, while the "1..n" part of 1599 the multiplicity mandates that at least one SUPAPolicyStatement 1600 MUST be aggregated by this particular SUPAPolicyAtomic object. More 1601 specifically, a cardinality of "3..n" on the part side is 1602 incorrect, since that would also apply to SUPALogicStatements. The 1603 semantics of this aggregation are defined by the 1604 SUPAPAHasPolicyStmtDetail association class. 1606 5.3.2.2. The Association Class "SUPAPAHasPolicyStmtDetail" 1608 This is an association class, and defines the semantics of the 1609 SUPAPAHasPolicyStmts aggregation. This enables the attributes and 1610 relationships of the SUPAPAHasPolicyStmtDetail class to be used to 1611 constrain which SUPAPolicyStatements objects can be aggregated by 1612 this particular SUPAPolicyAtomic object instance. Attributes will 1613 be added to this class at a later time. 1615 5.4. The Concrete Class "SUPAPolicyComposite" 1617 This is a mandatory concrete class. This class is a type of 1618 PolicyContainer. SUPAPolicyComposite was abstracted from DEN-ng 1619 [2], and a version of this class is in the process of being added 1620 to the policy framework defined in the TM Forum ZOOM model [5]. 1622 A SUPAPolicyComposite class represents a SUPA Policy as a 1623 hierarchy of Policy objects, where the hierarchy contains 1624 instances of a SUPAPolicyAtomic and/or SUPAPolicyComposite 1625 object. Each of the SUPA Policy objects, including the outermost 1626 SUPAPolicyComposite object, are separately manageable. More 1627 importantly, the SUPAPolicyComposite object can aggregate any 1628 SUPAPolicy subclass. Hence, it can be used to form hierarchies of 1629 SUPAPolicies as well as associate SUPAPolicySubjects and/or 1630 SUPAPolicyTargets to a given SUPAPolicy. 1632 5.4.1. SUPAPolicyComposite Attributes 1634 This section defines the attributes of the SUPAPolicyComposite 1635 class. The combination of these two attributes provides a more 1636 flexible and powerful solution compared to [RFC3060] and [RFC3460]. 1638 Care must be taken in adding attributes to this class, because the 1639 behavior of SUPALogicStatements is very different than the behavior 1640 of SUPAECAPolicyRules. 1642 5.4.1.1. The Attribute "supaPCFailureStrategy" 1644 This is an optional non-negative enumerated integer attribute, 1645 whose values are used to define what action(s) should be taken if 1646 a failure occurs when executing a SUPAPolicy object that is 1647 contained in this SUPAPolicyComposite object. Values include: 1649 0: undefined 1650 1: stop execution 1651 2: attempt rollback on failed policy 1652 3: attempt rollback on all policies 1653 4: ignore failure and continue 1655 A value of 0 can be used as an error condition. A value of 1 means 1656 that ALL execution is stopped, and that other SUPAPolicies that 1657 otherwise would have been executed are ignored. A value of 2 means 1658 that execution is stopped, and a rollback of that SUPAPolicy (and 1659 ONLY that SUPAPolicy) is attempted. A value of 3 means that 1660 execution is stopped, and all SUPAPolicies that have been 1661 previously executed (including the one that just failed) are 1662 rolled back. A value of 4 means that any failure will be ignored, 1663 and all SUPAPolicies contained in this SUPAPolicyComposite object 1664 will be executed. 1666 5.4.1.2. The Attribute "supaPCIsMatchAll" 1668 This is an optional Boolean attribute. If its value is TRUE, then 1669 ALL SUPAPolicies that are contained in this SUPAPolicyComposite 1670 object will be evaluated, regardless of whether a SUPAPolicy fails 1671 to execute correctly or not. If its value is FALSE, then only the 1672 FIRST SUPAPolicy contianed in this SUPAPolicyComposite object will 1673 be evaluated. The default value is TRUE. 1675 5.4.2. SUPAPolicyComposite Relationships 1677 This section defines the relationships of SUPAPolicyComposite. 1679 5.4.2.1. The Aggregation "HasSUPAPolicies" 1681 This is a mandatory aggregation that defines the set of 1682 SUPAPolicies that are contained in the instance of this 1683 particular SUPAPolicyComposite object. The multiplicity of this 1684 relationship is defined as 0..1 on the aggregate 1685 (SUPAPolicyComposite) side, and 1..n on the part (SUPAPolicy) side. 1686 This means that this relationship is optional, but if it is 1687 instantiated, then one or more SUPAPolicy objects are contained in 1688 this particular SUPAPolicyComposite object. The semantics of this 1689 aggregation are implemented using the HasSUPAPolicyDetail 1690 association class. 1692 5.4.2.2. The Association Class "HasSUPAPolicyDetail" 1694 This is a mandatory concrete association class that defines the 1695 semantics of the HasSUPAPolicies aggregation. This enables the 1696 attributes and relationships of the HasSUPAPolicyDetail class to 1697 be used to constrain which SUPAPolicy objects can be aggregated 1698 by this particular SUPAPolicyComposite object instance. 1699 Attributes will be added to this class at a later time. 1701 5.5. The Abstract Class "SUPAPolicyStatement" 1703 This is a mandatory abstract class that separates the 1704 representation of a SUPAPolicy from its implementation. This 1705 abstraction is missing in [RFC3060], [RFC3460], [4], and [6]. 1706 SUPAPolicyStatement was abstracted from DEN-ng [2], and a version 1707 of this class is in the process of being added to the policy 1708 framework defined in the TM Forum ZOOM model [5]. 1710 A SUPAPolicyStatement contains an individual or group of related 1711 functions that are used to build different types of policies. This 1712 is implemented using the composite pattern [3], so hierarchies of 1713 SUPAPolicyStatements can be constructed. Note that the hierarchy 1714 is available for two of its three subclasses: SUPABooleanClause 1715 (which is for forming ECA policy rules) and SUPALogicClause (which 1716 is for forming declarative policies). SUPAEncodedClause does not 1717 need to use this pattern, since it already encoded the clause. 1719 This document defines three different types of policies: ECA policy 1720 rules, declarative policies, and encoded policies. These different 1721 types of policies can be used to define a goal to be achieved, a 1722 set of facts to be used, or a set of actions to take. Examples of 1723 actions include getting data from network elements or other 1724 sources, stating facts about the system being managed, writing a 1725 change to a configuration of one or more managed objects, and 1726 querying information about one or more managed objects. 1728 SUPAPolicyStatements are objects in their own right, which 1729 facilitates their reuse. SUPAPolicyStatements can aggregate a set 1730 of SUPAPolicyTerms and/or a set of SUPAECAComponents. The former 1731 enables a SUPAPolicyStatement to be constructed from a set of 1732 SUPAPolicy objects, which emphasizes reusability and facilitates 1733 machine-directed policy authoring. The latter enables a higher 1734 level of abstraction to be applied to SUPAECAPolicyRules (i.e., 1735 the Event, Condition, and Action clauses can be filled by the 1736 subclasses OF SUPAECAComponents (SUPAEvent, SUPACondition, and 1737 SUPAAction). 1739 SUPAPolicyStatements can also be aggregated by a SUPAPolicyAtomic 1740 object - this enables both ECA policy rules and declarative policy 1741 statements to use SUPAPolicyStatements to form their policy rules. 1743 A class diagram showing SUPAPolicyStatement is shown in Figure 8. 1745 +---------------------+ 1746 | HasSUPAPolicyDetail | 1747 +----------+----------+ 1748 ^ 1749 +-----------------+ | 1750 | |/ | 1751 +------------------+ | SUPAPolicy +--------+------+ 1752 | SUPAPolicyAtomic | | |\ | 1753 +--------+---------+ +---------+-------+ 1..n | 1754 0..n / \ / \ | 1755 A I | 1756 \ / I HasSUPAPolicies | 1757 | I | 1758 | SUPAPAHasPolicyStmts I | 1759 | I | 1760 | +------------------+------+-----------+ | 1761 | I I I | 1762 1..n \ / I I I | 1763 +-------+-----+-------+ +----------+-------+ I | 1764 | SUPAPolicyStatement | | SUPAPolicyAtomic | I | 1765 +-------+----+--------+ +------------+-----+ I | 1766 / \ / \ 1..n 0..n / \ I | 1767 I | A I | 1768 I | \ / I | 1769 I | | I | 1770 I | HasSUPAPolicyStatements | I | 1771 I +---------------+------------+ I | 1772 I ^ I | 1773 I | I | 1774 I | I | 1775 +----+----------+ +-----+-------------------+ I | 1776 I I | HasSUPAPolicyStmtDetail | I / \ 1777 I I +-------------------------+ I A 1778 I I I \ / 0..1 1779 +---+---+ +--------+----------+ +---------+----+------+ 1780 | Other | | SUPAEncodedClause | | SUPAPolicyComposite | 1781 | Sub | +-------------------+ +---------------------+ 1782 |Classes| 1783 +-------+ 1785 Figure 8: SUPAPolicyStatements and SUPAPolicy Classes 1787 Note that the SUPAPAHasPolicyStmts aggregation was defined in 1788 Section 5.3.2.1. 1790 Note that in Figure 8: 1792 o SUPAPolicyStatement is a subclass of SUPAPolicy 1793 o SUPAPolicyStatements are aggregated by SUPAPolicyAtomic, 1794 which is a subclass of SUPAPolicy 1795 o SUPAPolicyComposite aggregates SUPAPolicyAtomic as well as 1796 SUPAPolicyComposite instance 1797 o A SUPAEncodedClause is a subclass of SUPAPolicyStatement, 1798 and may be used by either a SUPAECAPolicyRule or a 1799 SUPALogicStatement 1800 o SUPAPolicyStatement has two subclasses that are not shown in 1801 Figure 8: SUPABooleanClause and SUPALogicClause (they are 1802 discussed in Sections 6.5 and 7.4, respectively) 1803 o Both the HasSUPAPolicyStatements and the HasSUPAPolicies 1804 aggregations are implemented as association classes 1806 When defined in an information model, a SUPAPolicyStatement MUST be 1807 represented as a separate object that aggregates its constituent 1808 components. However, a data model MAY map this definition to a 1809 more efficient form (e.g., flattening the SUPAPolicyStatement and 1810 its aggregated object instances into a single object instance). 1812 5.5.1. SUPAPolicyStatement Attributes 1814 This section defines the attributes of the SUPAPolicyStatement 1815 class. These attributes are inherited by all subclasses of the 1816 SUPAPolicyStatement class. 1818 5.5.1.1. The Attribute "supaPolicyStmtAdminStatus" 1820 This is an optional attribute, which is an enumerated non-negative 1821 integer. It defines the current administrative status of this 1822 SUPAPolicyStatement. 1824 This attribute can be used to place this particular 1825 SUPAPolicyStatement into a specific administrative state, such as 1826 enabled, disabled, or in test. Note that since a SUPAPolicy (e.g., 1827 a SUPAECAPolicyRule or a SUPALogicStatement) is made up of 1828 SUPAPolicyStatements, this enables all or part of a SUPAPolicy to 1829 be administratively controlled. Values include: 1831 0: Unknown (an error state) 1832 1: Enabled 1833 2: Disabled 1834 3: In Test (i.e., no operational traffic can be passed) 1836 Value 0 denotes an error that prevents this SUPAPolicyStatement 1837 from being used. Values 1 and 2 mean that this SUPAPolicyStatement 1838 is administratively enabled or disabled, respectively. A value of 1839 3 means that this SUPAPolicyStatement is in a special test mode and 1840 SHOULD NOT be used as part of an OAM&P policy. 1842 5.5.1.2. The Attribute "supaPolStmtExecStatus" 1844 This is an optional attribute, which is an enumerated non-negative 1845 integer. It defines whether this SUPAPolicyStatement is currently 1846 in use and, if so, what its execution status is. 1848 This attribute can be used to place this particular 1849 SUPAPolicyStatement into a specific execution state, such as 1850 enabled, disabled, or in test. Note that since a SUPAPolicy (e.g., 1851 a SUPAECAPolicyRule or a SUPALogicStatement) is made up of 1852 SUPAPolicyStatements, this enables all or part of a SUPAPolicy to 1853 be administratively controlled. Values include: 1855 0: Unknown (an error state) 1856 1: Completed (i.e., successfully executed, but now idle) 1857 2: Working (i.e., in use and no errors reported) 1858 3: Not Working (i.e., in use, but errors have been reported) 1859 4: In Test (i.e., cannot be used as part of an OAM&P policy) 1860 5: Available (i.e., could be used, but currently isn't) 1861 6: Not Available (i.e., not available for use) 1863 Value 0 denotes an error that prevents this SUPAPolicyStatement 1864 from being used. Value 1 means that this SUPAPolicyStatement has 1865 successfully finished execution, and is now idle. Values 1-3 mean 1866 that this SUPAPolicyStatement is in use; in addition, this 1867 SUPAPolicyStatement is working correctly, not working correctly, or 1868 in a special test state, respectively. A test state signifies that 1869 it SHOULD NOT be used to evaluate OAM&P policies. Values 4-5 mean 1870 that this SUPAPolicyStatement is not currently in use; a value of 4 1871 means that it is available and could be used, while a value of 5 1872 means that it is unavailable. 1874 5.5.1.3. The Attribute "supaPolStmtIsCNF" 1876 This is an optional Boolean attribute. If its value is true, then 1877 this SUPAPolicyStatement is in Conjunctive Normal Form (CNF). In 1878 Boolean logic, a formula that is in CNF is conceptually an AND of 1879 ORs. Otherwise, it is in Disjunctive Normal Form (i.e., an OR of 1880 ANDs). 1882 5.5.2. SUPAPolicyStatement Subclasses 1884 As stated before, the primary purpose of SUPAPolicyStatement is to 1885 define a common type of Policy statement that can be used to 1886 represent policy content regardless of the type of SUPAPolicy that 1887 is being used (e.g., it is independent of the requirements of a 1888 SUPAECAPolicyRule or a SUPALogicStatement). 1890 The GPIM currently defines one subclass of SUPAPolicyStatement, 1891 called a SUPAEncodedClause, which can be used by both 1892 SUPAECAPolicyRules as well as SUPALogicStatements. Note that 1893 subclasses dedicated to the specific use of a SUPAECAPolicyRule 1894 and a SUPALogicStatement are defined in Sections 6.5 and 7.4, 1895 respectively. 1897 There are three principal subclasses of SUPAPolicyStatement: 1899 o SUPAEncodedClause, which is a mechanism to directly encode the 1900 content of the SUPAPolicyStatement into a set of attributes; 1901 this is described in more detai lin Section 5.5.2.1. 1902 o SUPABooleanClause, which defines a SUPAPolicyStatement as a 1903 set of one or more clauses; multiple clauses may be combined 1904 with Boolean AND and OR operators. This defines a SUPAPolicy 1905 as a completely reusable set of SUPAPolicy objects that are 1906 structured in an ECA form, and is described in more detail in 1907 Section 6.5. 1908 o SUPALogicClause, which defines a SUPAPolicyStatement as either 1909 a fact or a clause; both are expressed in first-order logic. 1910 This defines a SUPAPolicy as a completely reusable set of 1911 SUPAPolicy objects that are structured in FOL, and is 1912 described in more detail in Section 7.4. 1914 A SUPAPolicy MAY be constructed using any combination of the above 1915 three subclasses. 1917 Both SUPAECAPolicyRules (see Section 6) and SUPALogicStatements 1918 (see section 7) MUST use SUPAPolicyStatements to define their 1919 content. This enables the content of these different types of 1920 Policies to be represented in a common manner. 1922 Both SUPAECAPolicyRules and SUPALogicStatements MAY use a 1923 SUPAEncodedClause to define their content. 1925 SUPAECAPolicyRules SHOULD also use a SUPABooleanClause to define 1926 its content, while SUPALogicStatements SHOULD also use a 1927 SUPALogicClause to define its content. 1929 5.5.2.1. The Concrete Class "SUPAEncodedClause" 1931 This is a mandatory concrete class that specializes (i.e., is a 1932 subclass of) a SUPAPolicyStatement. It defines a generalized 1933 extension mechanism for representing SUPAPolicyStatements that 1934 have not been modeled with other SUPAPolicy objects. Rather, the 1935 Policy Clause is directly encoded into the attributes of the 1936 SUPAEncodedClause. Note that other subclasses of 1937 SUPAPolicyStatement use SUPAPolicy objects to define their 1938 content. 1940 This class provides the developer a tradeoff of efficiency vs. 1941 reusability. SUPAEncodedClause was abstracted from DEN-ng [2], 1942 and a version of this class is in the process of being added to 1943 the policy framework defined in the TM Forum ZOOM model [5]. 1945 This class uses two of its attributes (supaPolicyClauseContent and 1946 supaPolicyClauseFormat) for defining the content and format of a 1947 vendor-specific policy statement. This allows direct encoding of 1948 the policy statement, without having the "overhead" of using other 1949 objects. However, note that while this method is efficient, it 1950 does not reuse other SUPAPolicy objects. Rather, it can be thought 1951 of as a direct encoding of the policy statement. SUPAEncodedClause 1952 was abstracted from DEN-ng [2]. 1954 5.5.2.1.1. SUPAEncodedClause Attributes 1956 This section defines the attributes of the SUPAEncodedClause class. 1958 5.5.2.1.1.1. The Attribute "supaClauseContent" 1960 This is a mandatory string attribute, and defines the content of 1961 this encoded clause of this clause. It works with another attribute 1962 of the SUPAEncodedClause class, called supaClauseFormat, which 1963 defines how to interpret this attribute. These two attributes form 1964 a tuple, and together enable a machine to understand the syntax and 1965 value of the encoded clause for the object instance of this class. 1966 This is based on the DEN-ng class design [2]. 1968 5.5.2.1.1.2. The Attribute "supaClauseFormat" 1970 This is a mandatory string attribute, and defines the format of 1971 this encoded clause. It works with another attribute of the 1972 SUPAEncodedClause class, called supaClauseContent, which 1973 defines the content (i.e., the value) of the encoded clause. These 1974 two attributes form a tuple, and together enable a machine to 1975 understand the syntax and value of the encoded clause for the 1976 object instance of this class. This is based on the DEN-ng class 1977 design [2]. 1979 5.5.2.1.1.3. The Attribute "supaClauseResponse" 1981 This is an optional Boolean attribute that emulates a Boolean 1982 response of this clause, so that it may be combined with other 1983 subclasses of the SUPAPolicyStatement that provide a status as to 1984 their correctness and/or evaluation state. 1986 5.5.3. SUPAPolicyStatement Relationships 1988 This section defines the relationships of the SUPAPolicyStatement 1989 class. 1991 5.5.3.1. The Aggregation "SUPAPolicyTermsInStmt" 1993 This is a mandatory aggregation that defines the set of 1994 SUPAPolicyTerms that are aggregated by this instance of this 1995 SUPAPolicyStatement. This enables a SUPAPolicyStatement to be 1996 constructed from a {variable, operator, value} 3-tuple. The 1997 multiplicity of this relationship is defined as 0..n on the 1998 aggregate (SUPAPolicyStatement) side, and 0..n on the part 1999 (SUPAPolicyTerm) side. This means that this relationship is 2000 optional, but if it is instantiated, then a given 2001 SUPAPolicyStatement may contain zero or more SUPAPolicyTerms, and 2002 a given SUPAPolicyTerm may be contained in zero or more 2003 SUPAPolicyStatements. This enables SUPAPolicyTerms to be stored 2004 in a PolicyRepository before they are bound to one or more 2005 SUPAPolicyStatements (and vice-versa). The semantics of this 2006 aggregation are implemented using the SUPAPolicyTermsInStmtDetail 2007 association class. 2009 5.5.3.2. The Association Class "SUPAPolicyTermsInStmtDetail" 2011 This is a mandatory abstract association class that defines the 2012 semantics of the SUPAPolicyTermsInStmt aggregation. This enables 2013 the attributes and relationships of the SUPAPolicyTermsInStmt 2014 class to be used to constrain which SUPAPolicyStatement objects 2015 can aggregate which SUPAPolicyTerm objects. 2017 Attributes will be added to this class at a later time. 2019 5.5.3.2.1 SUPAPolicyStmtDetail Attributes 2021 No attributes are currently defined for the SUPAPolicyStmtDetail 2022 association class. 2024 5.6. The Abstract Class "SUPAPolicySubject" 2026 This is an optional class that defines the set of managed entities 2027 that authored, or are otherwise responsible for, this 2028 SUPAPolicyStatement. Note that a SUPAPolicySubject does NOT 2029 evaluate or execute SUPAPolicies. Its primary use is for 2030 auditability. 2032 A SUPAPolicySubject SHOULD be mapped to a role (e.g., using the 2033 role-object pattern, as DEN-ng does). This enables role-based 2034 access control to be used to restrict which entities can author a 2035 given policy. Note that Role is a type of Metadata. 2037 SUPAPolicySubject was abstracted from DEN-ng [2], and a version of 2038 this class is in the process of being added to the policy framework 2039 defined in the TM Forum ZOOM model [5]. A class diagram is shown in 2040 Figure 9. 2042 +------------------------+ 2043 | HasSUPAPolicyTgtDetail | 2044 +-----------+------------+ 2045 ^ 2046 | 0..n +------------+ 2047 | \| | 2048 +------------+-----------------+ | 2049 | SUPAPolicyTargets /| | 2050 | | SUPAPolicy | 2051 | 0..n | | 2052 | SUPAPolicySubjects \| | 2053 | +------------+---------------+ | 2054 | | ^ /| | 2055 | | | +------------+ 2056 | | | / \ 2057 | | +----------+--------------+ I 2058 | | | HasSUPAPolicySubjDetail | I 2059 | | +-------------------------+ I 2060 | | I 2061 | | +--------------------+------+---------------+ 2062 | | I I I 2063 | | I I I 2064 | | I I I 2065 | | 0..1 +-------+---------+ 0..1 +--------+-------+ (other 2066 | | / \| | / \| | SUPAPolicy 2067 | +--- A +SUPAPolicySubject| +-- A +SUPAPolicyTarget| subclasses) 2068 | \ /| | | \ /| | 2069 | +-----------------+ | +----------------+ 2070 | | 2071 +-----------------------------+ 2073 Figure 9. SUPAPolicySubject and SUPAPolicyTarget 2075 In Figure 9: 2077 o SUPAPolicySubject and SUPAPolicyTarget are both subclasses 2078 of SUPAPolicy 2079 o Both the SUPAPolicyTargets amd the SUPAPolicySubjects 2080 aggregations are implemented as association classes 2081 o The multiplicity of both of the above aggregations are 0..1 2082 on the aggregate (SUPAPolicySubject or SUPAPolicyTarget) side 2083 and 0..n on the target (i.e., SUPAPolicy) side, respectively. 2084 This means that both aggregations are optional. If either is 2085 instantiated, then a SUPAPolicySubject or a SUPAPolicyTarget 2086 MAY contain zero or more SUPAPolicy object instances 2088 This model assumes that appropriate SUPAPolicySubject and 2089 SUPAPolicyTarget objects are added as subclasses of SUPAPolicy. If 2090 this is not the case, then the part side of both aggregations MUST 2091 be changed to where those objects are identified. 2093 5.6.1. SUPAPolicySubject Attributes 2095 This section define the attributes of the SUPAPolicySubject class. 2097 5.6.1.1. The Attribute "supaPolicySubjectIsAuthenticated" 2099 This is an optional Boolean attribute. If the value of this 2100 attribute is true, then this SUPAPolicySubject has been 2101 authenticated and can be used to verify the authorship of a 2102 SUPAPolicy. 2104 5.6.2. SUPAPolicySubject Relationships 2106 This section defines the relationships of the SUPAPolicySubject 2107 class. 2109 5.6.2.1. The Relationship "SUPAPolicySubjects" 2111 This is an optional association that defines the set of 2112 SUPAPolicySubjects that are associated with this particular 2113 SUPAPolicy object. The multiplicity of this relationship is 2114 defined as 0..1 on the SUPAPolicySubject side, and 0..n on the 2115 SUPAPolicy side. This means that this relationship is optional, 2116 but if it is implemented, then this particular SUPAPolicy object 2117 was authored by this set of SUPAPolicySubjects. The semantics of 2118 this association are implemented using the SUPAPolicySubjectDetail 2119 association class. 2121 5.6.2.2. The Association Class "SUPAPolicySubjectDetail" 2123 This is an optional concrete association class that defines the 2124 semantics of the SUPAPolicySubjects association. This enables the 2125 attributes and relationships of the SUPAPolicySubjectDetail class 2126 to be used to constrain which SUPAPolicySubject objects can be 2127 used to author this particular SUPAPolicy object instance. 2129 5.6.2.2.1. SUPAPolicySubjectDetail Attributes 2131 Currently, one attribute is defined for the 2132 SUPAPolicySubjectDetail association class. 2134 5.6.2.2.1.1. The Attribute "supaPolicySubjectIsVerified" 2136 This is an optional Boolean attribute. If the value of this 2137 attribute is true, then this SUPAPolicySubject has been verified 2138 to be the author of this particular SUPAPolicy object instance. 2140 5.7. The Abstract Class "SUPAPolicyTarget" 2142 SUPAPolicyTarget was abstracted from DEN-ng [2], and a version of 2143 this class is in the process of being added to the policy framework 2144 defined in the TM Forum ZOOM model [5]. Figure 9 shows a class 2145 diagram of the SUPAPolicyTarget. 2147 A PolicyTarget is a set of managed entities that a SUPAPolicy is 2148 applied to. This is determined by two conditions. 2150 First, the set of managed entities that are to be affected by the 2151 SUPAPolicy must all agree to play the role of a SUPAPolicyTarget. 2152 In general, a managed entity may or may not be in a state that 2153 enables SUPAPolicies to be applied to it to change its state; 2154 hence, a negotiation process may need to occur to enable the 2155 SUPAPolicyTarget to signal when it is willing to have 2156 SUPAPolicies applied to it. 2158 Second, a SUPAPolicyTarget must be able to either process (either 2159 directly or with the aid of a proxy) SUPAPolicies or receive the 2160 results of a processed SUPAPolicy and apply those results to 2161 itself. If a proposed SUPAPolicyTarget meets both of these 2162 conditions, it SHOULD set its supaPolicyTargetEnabled Boolean 2163 attribute to a value of TRUE. 2165 A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the 2166 role-object pattern). Note that Role is a type of Metadata. 2168 5.7.1. SUPAPolicyTarget Attributes 2170 There are currently no attributes defined for the 2171 SUPAPolicyTarget class. 2173 5.7.2. SUPAPolicyTarget Relationships 2175 This section defines the relationships of the SUPAPolicyTarget 2176 class. 2178 5.7.2.1. The Relationship "SUPAPolicyTargets" 2180 This is an optional aggregation that defines the set of 2181 SUPAPolicyTargets that are contained in the instance of this 2182 particular SUPAPolicy object. This defines the set of entities that 2183 will be operated on by this particular SUPAPolicy object. The 2184 multiplicity of this relationship is defined as 0..1 on the 2185 aggregate (SUPAPolicy) side, and 0..n on the part 2186 (SUPAPolicyTarget) side. This means that this relationship is 2187 optional, but if it is implemented, then this particular SUPAPolicy 2188 object will operate on this set of SUPAPolicyTargets. The semantics 2189 of this aggregation are implemented using the 2190 HasSUPAPolicyTgtDetail association class. 2192 5.7.2.2. The Association Class "SUPAPolicyTargetDetail" 2194 This is an optional concrete association class that defines the 2195 semantics of the SUPAPolicyTargets aggregation. This enables the 2196 attributes and relationships of the SUPAPolicyTargetDetail class 2197 to be used to constrain which SUPAPolicyTarget objects can be 2198 operated on by this particular SUPAPolicy object instance. 2200 5.7.2.2.1. SUPAPolicyTargetDetail Attributes 2202 Currently, one attribute is defined for the SUPAPolicyTargetDetail 2203 association class 2205 5.7.2.2.1.1. The Attribute "supaPolicyTargetEnabled" 2207 This is an optional Boolean attribute. If its value is TRUE, then 2208 this indicates that this SUPAPolicyTarget is currently able to 2209 have SUPAPolicies applied to it. Otherwise, this SUPAPolicyTarget 2210 is not able to have SUPAPolicies applied to it. 2212 5.8. The Abstract Class "SUPAPolicyTerm" 2214 This is a mandatory abstract class that is the parent of SUPAPolicy 2215 objects that can be used to define a standard way to test or set 2216 the value of a variable. It does this by defining a 3-tuple, in the 2217 form {variable, operator, value}, where each element of the 3-tuple 2218 is defined by a concrete subclass of the appropriate type (i.e., 2219 SUPAPolicyVariable, SUPAPolicyOperator, and SUPAPolicyValue, 2220 respectively). For example, a generic test of the value of a 2221 variable is expressed as {variable, operator, value}. 2222 SUPAPolicyTerm was abstracted from DEN-ng [2]. 2224 SUPAPolicyTerm is defined as an abstract class for two reasons: 2226 1. This enables a single aggregation (SUPAPolicyTermsInStmt; see 2227 section 5.8.2.1) to be used to specify which object instances 2228 of which SUPAPolicyTerm subclasses are contained by a 2229 particular SUPAPolicyStatement object instance. Otherwise, a 2230 set of three aggregations would be required. 2232 2. This enables a single class (SUPAPolicyTermsInStmtDetail; see 2233 section 5.8.2.2) to be used as a superclass to define which 2234 one of its subclasses participates in this relationship. The 2235 advantage of this design is that as more SUPAPolicyTerm 2236 subclasses are added in the future, the SUPAPolicyStatement 2237 object is not affected. 2239 This design emphasizes flexibility and genericity of the model. 2240 Specifically, this means that the concept of creating a 2241 SUPAPolicyStatement can take a generic form, consisting of the 2242 tuple {PolicyVariable, PolicyOperator, PolicyValue}. Note that this 2243 is only one option for constructing SUPAPolicyStatements, and is 2244 not mandatory; hence, the multiplicity of the SUPAPolicyTermsInStmt 2245 aggregation (see Section 5.8.2.) is 0..n - 0..n. 2247 This design is in marked contrast to most existing designs. For 2248 example, [RFC3060], [RFC3460], and [4] do not define an ECA Policy 2249 Rule; rather, they are limited to a Policy Rule that only has a 2250 condition clause and an action clause. This means that there is no 2251 mechanism for the system to trigger when a Policy Rule should be 2252 evaluated (because there is no event clause). This makes it very 2253 difficult to simulate what will happen when a policy rule is 2254 executed. In addition, [RFC3060], [RFC3460], and [4] do not define 2255 any type of logic statement (or, for that matter, any other type 2256 of Policy Rule). 2258 5.8.1. SUPAPolicyTerm Attributes 2260 Currently, SUPAPolicyTerm defines a single attributes, as described 2261 in the following subsection. Constraints on the subclasses of 2262 SUPAPolicyTerm are applied to individual classes as attributes, or 2263 through the SUPAPolicyTermsInStmtDetail association class (see 2264 section 5.8.2.2). 2266 5.8.1.1 The Attribute "supaTermIsNegated" 2268 This is an optional Boolean attribute. If the value of this 2269 attribute is true, then this particular SUPAPolicyTerm subclass 2270 is negated; otherwise, it is not. This is based on the DEN-ng 2271 class design [2]. 2273 5.8.2. SUPAPolicyTerm Relationships 2275 Currently, SUPAPolicyTerm participates in a single relationship, 2276 as described in the following subsection. 2278 5.8.2.1. The Aggregation "SUPAPolicyTermsInStmt" 2280 This is a mandatory aggregation that defines the set of 2281 SUPAPolicyTerms that are contained in this SUPAPolicyStatement. 2282 The multiplicity of this relationship is defined as 0..n on the 2283 aggregate (SUPAPolicyStatement) side, and 0..n on the part 2284 (SUPAPolicyTerm) side. This means that a SUPAPolicyStatement does 2285 not have to contain a SUPAPolicyTerm; this is typically true for 2286 SUPALogicStatement. However, if a SUPAPolicyStatement 2287 does require one or more SUPAPolicyTerms, then those may be 2288 defined using this aggregation. The semantics of this aggregation 2289 are implemented using the SUPAPolicyTermsInStmtDetail association 2290 class. 2292 5.8.2.2. The Association Class "SUPAPolicyTermsInStmtDetail" 2294 This is a mandatory abstract association class that defines the 2295 semantics of the SUPAPolicyTermsInStmt aggregation. This enables 2296 the attributes and relationships of the SUPAPolicyTermsInStmtDetail 2297 class to be used to constrain which SUPAPolicyTerm objects can be 2298 aggregated by this particular SUPAPolicyStatement object instance. 2300 The preferred design is to keep this association class abstract, 2301 and create three subclasses from it that constrain the set of 2302 SUPAPolicyVariables, SUPAPolicyOperators, and SUPAPolicyValues 2303 that are used with this particular SUPAPolicyStatement. This 2304 provides a direct and simple mapping to optimized data models. 2305 Alternatively, appropriate attributes could be added to this 2306 association class to define the constraint, but such attributes 2307 would also have to take into account the type of PolicyTerm 2308 subclass that is being constrained. 2310 5.8.2.2.1. SUPAPolicyTermsInStmtDetail Attributes 2312 Currently, SUPAPolicyTermsInStmtDetail defines a single generic 2313 attribute, as described below. 2315 5.8.2.2.1.1. The Attribute "supaPolTermOCLConstraint" 2317 This is an optional string attribute that specifies a constraint 2318 to be applied. The constraint is defined in OCL 2.0. It is 2319 independent of the type of SUPAPolicyTerm that it applies to. 2321 5.8.3. SUPAPolicyTerm Subclasses 2323 The following three subsections define three subclasses of the 2324 SUPAPolicyTerm class. 2326 5.8.3.1. The Concrete Class "SUPAPolicyVariable" 2328 This is a mandatory concrete class that defines information that 2329 forms a part of a SUPAPOlicyStatement. It specifies a concept or 2330 attribute that should be compared to a value, as specifed in this 2331 SUPAPolicyStatement. If it is used in a SUPAECAPolicyRule, then 2332 its value MAY be able to be changed at any time. However, if it 2333 is used in a SUPALogicStatement, then it is typically bound to an 2334 expression, and keeps a single value during its entire lifetime. 2335 SUPAPolicyVariable was abstracted from DEN-ng [2]. 2337 The value of a SUPAPolicyVariable is typically compared to the 2338 value of a SUPAPolicyValue using the type of operator defined in 2339 a SUPAPolicyOperator. 2341 SUPAPolicyVariables are used to abstract the representation of a 2342 SUPAPolicyRule from its implementation. Therefore, the design of 2343 SUPAPolicyVariables depends on two important factors. 2345 First, some SUPAPolicyVariables are restricted in the values and/or 2346 the data type that they may be assigned. For example, port numbers 2347 cannot be negative, and they cannot be floating-point numbers. 2348 Thus, any SUPAPolicyVariable can have a set of constraints 2349 associated with it that restrict the value, data type, and other 2350 semantics of the SUPAPolicyVariable when used in a particular 2351 SUPAPolicyStatement. Second, there is a high likelihood that 2352 specific applications will need to use their own variables that 2353 have specific meaning to a particular application. 2355 In general, there are two ways to apply constraints to an object 2356 instance of a SUPAPolicyVariable: 2358 o use a specific subclass of PolicyVariable, which has these 2359 constraints already applied to the attribute to be used 2360 o define constraints in the supaPolTermConstraints attribute 2361 of the SUPAPolicyTermsInStmtDetail association class (see 2362 Section 5.8.2.2.2.1.) 2364 The former approach was used in [RFC3460]. The problem with this 2365 approach is that it requires two additional subclasses (called 2366 PolicyImplicitVariable and PolicyExplicitVariable) with two 2367 different semantics, as well as three different associations. It 2368 also leads to class explosion. This draft keeps the idea of the 2369 class hierarchy for backwards compatibility, but streamlines the 2370 implementation. 2372 The latter approach is recommended, due to the use of established 2373 software patterns that can be used to populate the attribute(s) 2374 of the SUPAPolicyTermsInStmtDetail association class, or any 2375 subclass that is defined to refine its semantics. 2377 5.8.3.1.1. Problems with the RFC3460 Version of PolicyVariable 2379 First, [RFC3460] says: "Variables are used for building 2380 individual conditions". While this is true, variables can also be 2381 used for building individual actions. This is reflected in the 2382 SUPAPolicyVariable definition. 2384 Second, [RFC3460] says: "The variable specifies the property of a 2385 flow or an event that should be matched when evaluating the 2386 condition." While this is true, variables can be used to test many 2387 other things than "just" a flow or an event. This is reflected in 2388 the SUPAPolicyVariable definition. 2390 Third, the [RFC3460] definition requires the use of associations 2391 in order to properly constrain the variable (e.g., define its 2392 data type, the range of its allowed values, etc.). This is both 2393 costly and inefficient. 2395 Fourth, in [RFC3460], defining constraints for a variable is 2396 limited to associating the variable with a PolicyValue. This is 2397 both cumbersome (because associations are costly; for example, 2398 they equate to a join in a relational database management system), 2399 and not scalable, because it is prone to proliferating PolicyValue 2400 classes for every constraint (or range of constraints) that is 2401 possible. Therefore, in SUPA, this mechanism is replaced with 2402 using an association to a generic SUPAConstraint object. 2404 Fifth, [RFC3460] is tightly bound to the DMTF CIM schema [4]. 2405 The CIM is a data model (despite its name), because: 2407 o It uses keys and weak relationships, which are both concepts 2408 from relational algebra and thus, not technology-independent 2409 o It has its own proprietary modeling language 2410 o It contains a number of concepts that are not defined in UML 2411 (including overriding keys for subclasses) 2413 Finally, the class hierarchy has two needless classes, called 2414 SUPAImplicitVariable and SUPAExplicitVariable. These classes do 2415 not define any attributes or relationships, and hence, do not 2416 add any semantics to the model. 2418 5.8.3.1.2. SUPAPolicyVariable Attributes 2420 Currently, SUPAPolicyVariable defines three generic attributes, 2421 as described below. 2423 5.8.3.1.2.1. The Attribute "supaAllowedValueTypes[0..n]" 2425 This is an optional array of string attributes. Each attribute 2426 specifies a constraint to be applied using OCL 2.0. This provides 2427 a more rigorous and flexible treatment of constraints than is 2428 possible in [RFC3460]. 2430 5.8.3.1.2.2. The Attribute "supaPolVarContent" 2432 This is a string attribute that contains the value of the 2433 SUPAPolicyVariable object instance. Its data type is defined by 2434 the supaPolVarType class attribute. 2436 5.8.3.1.2.3. The Attribute "supaPolVarType" 2438 This is a string attribute that contains the data type of the 2439 SUPAPolicyVariable object instance. Its value is defined by 2440 the supaPolVarContent class attribute. 2442 5.8.3.1.3. SUPAPolicyVariable Subclasses 2444 A set of SUPAPolicyVariable subclasses will be defined in the 2445 next version of this document. These are included for backwards 2446 compatibility with existing designs based on [RFC3460]. This is 2447 a more complex approach, and is not recommended. 2449 5.8.3.2. The Concrete Class "SUPAPolicyOperator" 2451 This is a mandatory concrete class for modeling different types of 2452 operators that are used in a SUPAPolicyStatement. 2454 A SUPAPolicyOperator is a mandatory concrete class that defines 2455 the type of operator to be applied to a SUPAPolicyStatement that 2456 is created from a set of SUPAPolicyTerms. This class is based on 2457 a similar class defined in [2]. 2459 The restriction of the type of operator used in a 2460 SUPAPolicyStatement restricts the semantics that can be expressed 2461 in that SUPAPolicyStatement. 2463 5.8.3.2.1. Problems with the RFC3460 Version 2465 Note that this class is NOT present in either RFC[3060] or 2466 [RFC3460]; instead, both hardwire the operator to a "MATCH" 2467 function. Quoting from [RFC3460]: 2469 "A simple condition models an elementary Boolean expression of 2470 the form 'variable MATCHes value". However, the formal 2471 notation of the SimplePolicyCondition, together with its 2472 associations, models only a pair, (, ). The 2473 'MATCH' operator is not directly modeled -- it is implied. 2474 Furthermore, this implied 'MATCH' operator carries overloaded 2475 semantics [sic]." 2477 In stark contrast to this, SUPA defines a SUPAPolicyOperator as a 2478 formal subclass of SUPAPolicyTerm. A single attribute, called 2479 supaPolOpType, carries the operator to be applied to the 2480 SUPAECAPolicyRule. This has the important advantage of enabling 2481 ECA policy rules of varying functionality to be created by a 2482 human or a machine. 2484 5.8.3.2.2. SUPAPolicyOperator Attributes 2486 Currently, SUPAPolicyOperator defines a single generic attribute, 2487 as described below. 2489 5.8.3.2.2.1. The Attribute "supaPolOpType" 2491 This is a mandatory non-negative enumerated integer that specifies 2492 the various types of operators that are allowed to be used in this 2493 particular SUPAPolicyStatement. Values include: 2495 0: Unknown 2496 1: Match 2497 2: Greater than 2498 3: Greater than or equal to 2499 4: Less than 2500 5: Less than or equal to 2501 6: Equal to 2502 7: Not equal to 2503 8: IN 2504 9: NOT IN 2505 10: SET 2506 11: CLEAR 2508 Note that 0 is an unacceptable value. Its purpose is to support 2509 dynamically building a SUPAPolicyStatement by enabling the 2510 application to set the value of this attribute to a standard 2511 default value if the real value is not yet known. 2513 5.8.3.3. The Concrete Class "SUPAPolicyValue" 2515 The SUPAPolicyValue class is a mandatory concrete class for 2516 modeling different types of values and constants that occur in a 2517 PolicyStatement. SUPAPolicyValue was abstracted from DEN-ng [2]. 2519 The value of a SUPAPolicyVariable is typically compared to the 2520 value of a SUPAPolicyValue using the type of operator defined in a 2521 SUPAPolicyOperator. 2523 SUPAPolicyValues are used to abstract the representation of a 2524 SUPAPolicyRule from its implementation. Therefore, the design of 2525 SUPAPolicyValues depends on two important factors. First, just as 2526 with SUPAPolicyVariables (see Section 5.8.3.1), some types of 2527 SUPAPolicyValues are restricted in the values and/or the data 2528 type that they may be assigned. Second, there is a high likelihood 2529 that specific applications will need to use their own variables 2530 that have specific meaning to a particular application. 2532 In general, there are two ways to apply constraints to an object 2533 instance of a SUPAPolicyValue: 2535 o use a specific subclass of PolicyValue, which has these 2536 constraints already applied to the attribute to be used 2537 o define constraints in the supaPolTermConstraints attribute 2538 of the SUPAPolicyTermsInStmtDetail association class (see 2539 Section 5.8.2.2.2.1.) 2541 The former approach was used in [RFC3460]. The problem with this 2542 approach is that it generates a set of classes, each having a 2543 single data type, to represent a primitive type. Hence, this 2544 approach may lead to class explosion. This draft keeps the idea 2545 of the class hierarchy for backwards compatibility, but 2546 streamlines the implementation. 2548 The latter approach is recommended, due to the use of established 2549 software patterns that can be used to populate the attribute(s) 2550 of the SUPAPolicyTermsInStmtDetail association class, or any 2551 subclass that is defined to refine its semantics. 2553 5.8.3.3.1. Problems with the RFC3460 Version of PolicyValue 2555 First, [RFC3460] says: It is used for defining values and 2556 constants used in policy conditions". While this is true, 2557 variables can also be used for building individual actions. This 2558 is reflected in the SUPAPolicyVariable definition. 2560 Second, the [RFC3460] definition requires the use of associations 2561 in order to properly constrain the variable (e.g., define its 2562 data type, the range of its allowed values, etc.). This is both 2563 costly and inefficient. 2565 Third, in [RFC3460], there is no generic facility for defining 2566 constraints for a PolicyValue. 2568 Fourth, [RFC3460] is tightly bound to the DMTF CIM schema [4]. 2569 The CIM is a data model (despite its name), because: 2571 o It uses keys and weak relationships, which are both concepts 2572 from relational algebra and thus, not technology-independent 2573 o It has its own proprietary modeling language 2574 o It contains a number of concepts that are not defined in UML 2575 (including overriding keys for subclasses) 2577 5.8.3.3.2. SUPAPolicyValue Attributes 2579 Currently, SUPAPolicyValue defines two generic attributes, as 2580 described below. 2582 5.8.3.3.2.1. The Attribute "supaPolValContent" 2584 This is a string attribute that contains the value of the 2585 SUPAPolicyValue object instance. Its data type is defined by 2586 the supaPolValType class attribute. 2588 5.8.3.3.2.2. The Attribute "supaPolValType" 2590 This is a string attribute that contains the data type of the 2591 SUPAPolicyValue object instance. Its value is defined by the 2592 supaPolValContent class attribute. 2594 5.8.3.3.3. SUPAPolicyValue Subclasses 2596 A set of SUPAPolicyValue subclasses will be defined in the 2597 next version of this document. These are included for backwards 2598 compatibility with existing designs based on [RFC3460]. This is 2599 a more complex approach, and is not recommended. 2601 5.9. The Abstract Class "SUPAPolicyMetadata" 2603 THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT. 2605 SUPAPolicyMetadata was abstracted from DEN-ng [2]. A more complete 2606 representation of metadata, as defined in [2], is in the process 2607 of being added to the policy framework defined in the TM Forum 2608 ZOOM model [5]. 2610 5.9.1. SUPAPolicyMetadata Attributes 2612 THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT. 2614 5.9.2. SUPAPolicyMetadata Relationships 2616 THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT. 2618 6. SUPA ECAPolicyRule Information Model 2620 This section defines the classes, attributes, and relationships 2621 of the SUPA ECAPolicyRule Information Model (EPRIM). 2623 6.1. Overview 2625 Conceptually, the EPRIM is a set of subclasses that specialize the 2626 concepts defined in the GPIM for representing the components of a 2627 Policy that uses ECA semantics. This is shown in Figure 10. 2629 (Class of another model that SUPA is integrating into) 2630 | 2631 +---SUPAPolicy (see Section 5.2) 2632 | | 2633 | +---SUPAPolicyAtomic (see Section 5.3) 2634 | | | 2635 | | +---SUPAECAPolicyRule (see Section 6.4) 2636 | | | 2637 | | +---SUPAECAComponent (see Section 6.6) 2638 | | | 2639 | | +---SUPAEvent (see Section 6.6.3.1) 2640 | | | 2641 | | +---SUPACondition (see Section 6.6.3.2) 2642 | | | 2643 | | +---SUPAAction (see Section 6.6.3.3) 2644 | | 2645 | +---SUPAPolicyComposite (see Section 5.4) 2646 | | 2647 | +---SUPAPolicyStatement (see Sections 5.5 and 6.5) 2648 | | | 2649 | | +---SUPAEncodedClause (see Section 5.5.2.1) 2650 | | | 2651 | | +---SUPABooleanClause (see Section 6.5.2) 2652 | | 2653 | +---SUPAPolicySubject (see Section 5.6) 2654 | | 2655 | +---SUPAPolicyTarget (see Section 5.7) 2656 | | 2657 | +---SUPAPolicyTerm (see Section 5.8) 2658 | | 2659 | +---SUPAPolicyMetadata (see Section 5.9) 2660 ... 2662 Figure 10: The EPRIM Refining the GPIM 2664 Specifically, the EPRIM specializes the SUPAPolicyAtomic class to 2665 create a SUPAECAPolicyRule; it also specializes the SUPAPolicy 2666 class to create a SUPAECAComponent, and the SUPAPolicyStatement to 2667 create a SUPABooleanClause. The SUPAECAPolicyRule uses the rest of 2668 the GPIM infrastructure to define a complete Policy model 2669 according to ECA semantics. 2671 The overall strategy for refining the GPIM is as follows: 2673 o SUPAECAPolicyRule is defined as a subclass of the GPIM 2674 SUPAPolicyAtomic class 2675 o A SUPAECAPolicyRule has event, condition, and action clauses; 2676 each of these are created by either a SUPABooleanClause or a 2677 SUPAEncodedClause (subclasses of SUPAPolicyStatement) 2678 o Both a SUPABooleanClause and a SUPAEncodedClause inherit the 2679 HasSUPAECAComponents aggregation, so both of these types of 2680 clauses can use SUPAECAComponents in their construction 2681 o A SUPAECAComponent defines SUPAEvent, SUPACondition, and 2682 SUPAAction objects that can optionally be used to create the 2683 event, condition, and action clauses of a SUPAECAPolicyRule 2684 o Both a SUPABooleanClause and a SUPAEncodedClause inherit the 2685 SUPAPolicyTermsInStmt aggregation, so both of these types of 2686 clauses can use SUPAPolicyTerms in their construction 2687 o An optional set of GPIM SUPAPolicySubjects can be defined to 2688 represent the authoring of a SUPAECAPolicyRule 2689 o An optional set of GPIM SUPAPolicyTargets can be defined to 2690 represent the set of managed entities that will be affected 2691 by this SUPAECAPolicyRule 2692 o An optional set of SUPAPolicyMetadata can be defined for any 2693 of the objects that make up a SUPAECAPolicyRule and/or a 2694 SUPAECAComponent 2696 6.2. Constructing a SUPAECAPolicyRule 2698 There are several different ways to construct a SUPAECAPolicyRule. 2699 The simplest approach is as follows: 2701 o Define three types of SUPABooleanClauses (see Section 6.7), 2702 one each for the event, condition, and action clauses that 2703 make up a SUPAECAPolicyRule (see Section 6.4) 2704 o Define a set of SUPAEvent, SUPACondition, and SUPAAction 2705 objects (see Section 6.5.1, 6.5.2, and 6.5.4, respectively), 2706 and associate each with the SUPABooleanClause that represents 2707 the event, condition, and action clauses, respectively, of the 2708 SUPAECAPolicyRule 2709 o Define a SUPAECAPolicyRule, which is a subclass of the GPIM 2710 SUPAPolicyAtomic class (see Section 5.3) 2712 o Aggregate the three SUPABooleanClauses into the 2713 SUPAECAPolicyRule 2714 o Optionally, define a set of SUPAPolicySubjects and 2715 SUPAPolicyTargets, and aggregate them into the 2716 SUPAECAPolicyRule 2717 o Optionally, define SUPAPolicyMetadata for any of the above 2718 objects, and aggregate them to the SUPAPolicy objects that 2719 the SUPAPolicyMetadata applies to 2721 6.3. Working With SUPAECAPolicyRules 2723 A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that 2724 MUST have three clauses, defined as follows: 2726 o The event clause defines a Boolean expression that, if 2727 TRUE, triggers the evaluation of its condition clause (if the 2728 event clause is not TRUE, then no further action for this 2729 policy rule takes place). 2730 o The condition clause defines a Boolean expression that, if 2731 TRUE, enables the actions in the action clause to be executed 2732 (if the condition clause is not TRUE, then no further action 2733 for this policy rule takes place). 2734 o The action clause is a set of actions, whose 2735 execution MAY be controlled by the SUPAMmetadata of the 2736 policy rule. 2738 Note that in theory, the condition clause of an ECA policy rule 2739 could also include multiple clauses (like, for example, a switch 2740 statement). Similarly, multiple action clauses (i.e., one for 2741 each distinct condition clause) could be included as well. This 2742 was done on a limited basis in DEN-ng. However, this complicates 2743 the overall design, so at this time, SUPA is not providing this 2744 facility. 2746 Each of the three clauses can be constructed from either a 2747 SUPAEncodedClause or a SUPABooleanClause. The advantage of using 2748 SUPAEncodedClauses is simplicity, as the content of the clause is 2749 encoded directly into the attributes of the SUPAEncodedClause. The 2750 advantage of using SUPABooleanClauses is reusability, since each 2751 term in each clause is potentially a reusable object. 2753 Since a SUPABooleanClause is a subclass of a SUPAPolicyStatement 2754 (see Section 5.5), it can aggregate SUPAPolicyTerm objects as well 2755 as SUPAECAComponent objects. Therefore, a SUPAECAPolicyRule can be 2756 built entirely from objects defined in the GPIM. As will be shown 2757 in Section 7.4, this is also true for SUPALogicStatements. 2759 The construction of a SUPAECAPolicyRule is shown in Figure 11, and 2760 is explained in Section 6.4. 2762 0..n +----------------------+ 2763 / \| | 2764 +--- A + SUPAPolicyAtomic | +-------------------+ 2765 | \ /| | | SUPAPolicy | 2766 | +---------+------------+ +----------+--------+ 2767 | / \ / \ 2768 | I I 2769 | I I 2770 | +------------+------------+ +------------+------------+ 2771 | | SUPAECAPolicyRule | | SUPAECAComponent | 2772 | +-------------------------+ +------------+------------+ 2773 | 1..n/ \ 2774 | | 2775 | +-------------------------+ | 2776 | |HasSUPAECAComponentDetail| | 2777 | +-------------+-----------+ | 2778 | ^ | 2779 | | | 2780 | | | 2781 +------------------------------+----------------+ 2782 HasSUPAECAComponents 2784 Figure 11. SUPAECAPolicyRule Clauses 2786 NOTE: This is a simplified design, inspired from [2]. The 2787 HasSUPAECAComponents aggregation is implemented using the 2788 HasSUPAECAComponentDetail association class. This is an abstract 2789 class further described in Section 6.4.2. It has three concrete 2790 subclasses, one each that correspond to the three subclasses of 2791 SUPAECAComponent (i.e., SUPAEvent, SUPACondition, and SUPAAction), 2792 which are all concrete. This enables one aggregation to define a 2793 set of constraints between a SUPAPolicyStatement and the set of 2794 Events, Conditions, and/or Actions that it can contain. 2796 6.4. The Concrete Class "SUPAECAPolicyRule" 2798 This is a concrete mandatory class. In keeping with the original 2799 DEN-ng model [1], this class is a PolicyContainer that contains 2800 PolicyEvents, PolicyConditions, PolicyActions, and optionally, 2801 PolicySubjects, PolicyTargets, and PolicyMetadata. As such, it 2802 does not have an inherent relationship with PolicySubject or 2803 PolicyTarget; these all represent the specific semantics for a 2804 particular SUPAPolicy. Hence, such semantics are defined in an 2805 instance of the SUPAPolicyComposite class that contains a 2806 SUPAECAPolicyRule, if they are required. 2808 An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an 2809 abstract class that represents a policy rule as a three-tuple, 2810 consisting of at least one event clause, one condition clause, and 2811 one action clause. Each clause MUST be defined by at least one 2812 SUPAPolicyStatement. Optionally, the SUPAECAPolicyRule MAY contain 2813 one or more SUPAPolicySubjects, one or more SUPAPolicyTargets, and 2814 one or more SUPAPolicyMetadata objects. 2816 There are two main ways that the event, condition, and action 2817 clauses of a SUPAECAPolicyRule can be populated: 2819 o Use a SUPAEncodedClause 2820 o Use a SUPABooleanClause using SUPAECAComponents and/or 2821 SUPAPolicyTerms 2823 Regardless of which approach is taken, the operation of a 2824 SUPAECAPolicyRule is identical: 2826 o the event clause specifies what triggers the evaluation 2827 of the SUPAECAPolicyRule 2828 o the condition clause specifies whether the condition clause 2829 has evaluated to TRUE or FALSE, and hence, whether the 2830 action clause should be executed or not 2831 o the action clause specifies the set of actions to be executed 2833 If there is more than one term, then these terms MUST be combined 2834 using any combination of logical AND, OR, and NOT operators to 2835 form a Boolean clause (i.e., a clause whose value is either TRUE 2836 or FALSE). For example, a valid event clause could be: "three 2837 events of type A AND NOT an event of type B". 2839 This behavior differentiates a SUPAECAPolicyRule from a 2840 SUPALogicStatement, which specifies the set of actions to perform, 2841 but not how to implement or execute them. 2843 The behavior of the event, condition, and action clauses MAY be 2844 specified using one or more SUPAMetadata objects that have been 2845 aggregated by the SUPAECAPolicyRule. Note that one or more 2846 SUPAMetadata objects may also be aggregated by any of the 2847 components of a SUPAECAPolicyRule. 2849 A SUPAECAPolicyRule MAY specify a set of SUPAPolicySubjects that 2850 have authored the SUPAECAPolicyRule. A SUPAECAPolicyRule MAY 2851 specify a set of SUPAPolicyTargets that define a set of managed 2852 objects that the actions of the SUPAECAPolicyRule MAY monitor 2853 and/or change their state. 2855 When defined in an information model, each of the event, condition, 2856 and action clauses MUST be represented as an aggregation between a 2857 SUPAECAPolicyRule (the aggregate) and a set of event, condition, or 2858 action objects (the components). However, a data model MAY map 2859 these definitions to a more efficient form (e.g., by flattening 2860 these three types of object instances, along with their respective 2861 aggregations, into a single object instance). 2863 The semantics of a SUPAECAPolicyRule may be conceptualized as 2864 follows: 2865 ON RECEIPT OF 2866 IF EVALUATES TO TRUE 2867 THEN EXECUTE 2868 END 2869 END 2871 In the above, a policy-event-clause, policy-condition-clause, and 2872 a policy-action-clause are each instances of either a 2873 SUPAEncodedClause or a SUPABooleanClause. 2875 SUPAECAPolicyRule was abstracted from DEN-ng [2], and a version 2876 of this class is in the process of being added to the policy 2877 framework defined in the TM Forum ZOOM model [5]. 2879 6.4.1. SUPAECAPolicyRule Attributes 2881 Currently, the SUPAECAPolicyRule defines three attributes, as 2882 described in the following subsections. 2884 6.4.1.1. The Attribute "supaECAPolicyIsMandatory" 2886 This is an optional Boolean attribute. If the value of this 2887 attribute is true, then this SUPAECAPolicyRule MUST be executed 2888 (i.e., its Event and Condition clauses are irrelevant, and the 2889 Action(s) specified in the Action clause MUST be executed). 2890 These actions will use the inhertied supaPolicyExecStrategy 2891 attribute to govern which of the Actions in this SUPAECAPolicyRule 2892 will be executed or not. 2894 6.4.1.2. The Attribute "supaECAPolicyPriority" 2896 This is a mandatory non-negative integer attribute that defines 2897 the priority of this particular SUPAECAPolicyRule. A larger value 2898 indicates a higher priority. A default value of 0 MAY be assigned. 2900 6.4.2. SUPAECAPolicyRule Relationships 2902 Currently, the SUPAECAPolicyRule defines a single aggregation 2903 between it and SUPAECAComponent, as described below. Note that 2904 the remaining functionality that SUPAECAPolicyRule requires is 2905 provided by other relationships within the GPIM and EPRIM. For 2906 example, the aggregation SUPAHasPolicyStmts (see section 5.3.2.1) 2907 defines the set of SUPAPolicyStatements that MUST be aggregated 2908 by this particular SUPAPolicyAtomic object. 2910 6.4.2.1. The Aggregation "SUPAECAPolicyRules" 2912 This is an optional aggregation that defines the set of SUPAEvents, 2913 SUPAConditions, and SUPAActions that are aggregated by this 2914 particular SUPAECAPolicyRule. The multiplicity of this aggregation 2915 is 0..1 on the aggregate (SUPAECAPolicyRule) side and 1..n on the 2916 part (SUPAECAComponent) side. This means that if this aggregation 2917 is defined, then at least one SUPAECAComponent must also be 2918 instantiated and aggregated by the SUPAECAPolicyRule. However, a 2919 SUPAECAComponent does not have to be instantiated when a 2920 SUPAECAComponent is instantiated; this enables SUPAECAComponent 2921 objects to be stored in a repository, for use as a library. The 2922 semantics of this aggregation are defined by the 2923 SUPAECADetail association class. 2925 6.4.2.1.1. The Association Class "HasSUPAECAComponentDetail" 2927 This is an optional association class, and defines the semantics 2928 of the HasSUPAECAComponent aggregation. This enables the 2929 attributes and relationships of the SUPAPAHasPolicyStmtDetail 2930 class to be used to constrain which SUPAPolicyStatements objects 2931 can be aggregated by this particular SUPAPolicyAtomic object 2932 instance. Attributes will be added to this class at a later time. 2934 6.4.3. SUPAECAPolicyRule Subclasses 2936 The composite pattern [3] is applied to the SUPAECAPolicyRule 2937 class, enabling it to be used as either a stand-alone policy rule 2938 or as a hierarchy of policy rules. This is shown in Figure 12. 2940 SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both 2941 inherit from SUPAECAPolicyRule. This means that they are both 2942 a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRules 2943 aggregation enables a particular SUPAECAPolicyRuleComposite 2944 object to aggregate both SUPAECAPolicyRuleComposite as well as 2945 SUPAECAPolicyRuleAtomic objects. In contrast, a 2946 SUPAECAPolicyRuleAtomic can NOT aggregate either a 2947 SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. 2949 1..n +-------------------+ 2950 \| | 2951 +--------------- + SUPAECAPolicyRule | 2952 | /| | 2953 | +--------+----------+ 2954 | / \ 2955 | HasSUPAECAPolicyRules I 2956 | I 2957 | I 2958 | I 2959 | +----------------+---------+ 2960 | I I 2961 / \ I I 2962 A I I 2963 0..1 \ / I I 2964 +-------+--------+---------+ +-----------+-----------+ 2965 |SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic| 2966 +--------------------------+ +-----------------------+ 2968 Figure 12. The Composite Pattern Applied to a SUPAECAPolicyRule 2970 6.4.3.1. The Concrete Class "SUPAECAPolicyRuleAtomic" 2972 This is a mandatory concrete class. This class is a type of 2973 PolicyContainer. SUPAECAPolicyRuleAtomic was abstracted from 2974 DEN-ng [2], and a version of this class is in the process of 2975 being added to the policy framework defined in the TM Forum ZOOM 2976 model [5]. 2978 A SUPAECAPolicyRuleAtomic class represents a SUPA ECA Policy Rule 2979 that can operate as a single, stand-alone, manageable object. Put 2980 another way, a SUPAECAPolicyRuleAtomic object can NOT be modeled as 2981 a set of hierarchical SUPAECAPolicyRule objects; if this is 2982 required, then a SUPAECAPolicyRuleComposite object should be 2983 used instead. 2985 6.4.3.1.1. SUPAECAPolicyRuleAtomic Attributes 2987 No attributes are currently defined for the SUPAECAPolicyRule 2988 class. 2990 6.4.3.1.2. SUPAECAPolicyRuleAtomic Relationships 2992 No relationships are currently defined for the SUPAECAPolicyRule 2993 class. 2995 6.4.3.2. The Concrete Class "SUPAECAPolicyRuleComposite" 2997 This is a mandatory concrete class. This class is a type of 2998 PolicyContainer. SUPAECAPolicyRuleComposite was abstracted from 2999 DEN-ng [2], and a version of this class is in the process of 3000 being added to the policy framework defined in the TM Forum ZOOM 3001 model [5]. 3003 A SUPAECAPolicyRuleComposite class represents a SUPA ECA Policy 3004 Rule as a hierarchy of Policy objects, where the hierarchy 3005 contains instances of a SUPAECAPolicyRuleAtomic and/or 3006 SUPAECAPolicyRuleComposite object. Each of the SUPA Policy 3007 objects, including the outermost SUPAECAPolicyRuleComposite 3008 object, are separately manageable. More importantly, the 3009 SUPAECAPolicyRuleComposite object can aggregate any 3010 SUPAECAPolicyRule subclass. Hence, it can be used to form 3011 hierarchies of SUPAECAPolicyRules as well as associate 3012 SUPAPolicySubjects and/or SUPAPolicyTargets to a given 3013 SUPAECAPolicyRule. 3015 6.4.3.2.1. SUPAECAPolicyRuleAtomic Attributes 3017 Currently, the SUPAECAPolicyRule defines two attributes, as 3018 described in the following subsections. 3020 6.4.3.2.1.1. The Attribute "supaECAEvalStrategy" 3022 This is a mandatory, non-zero, integer attribute that enumerates 3023 a set of allowable alternatives that define how the actions in a 3024 SUPAPolicyRuleComposite are evaluated. Values include: 3026 0: undefined 3027 1: execute all actions regardless of their execution status 3028 2: execute all actions until one or more actions fail 3029 3: execute only the highest priority action(s) 3031 6.4.3.2.1.2. The Attribute "supaECAFailStrategy" 3033 This is a mandatory, non-zero, integer attribute that enumerates 3034 a set of allowable alternatives that define how actions that do 3035 not execute successfully should be handled. Values include: 3037 0: undefined 3038 1: rollback just the failed action 3039 2: rollback all actions that have been executed in this 3040 SUPAECAPolicyRule 3041 3: ignore failures and continue 3043 6.4.3.2.2. SUPAECAPolicyRuleComposite Relationships 3045 Currently, a single aggregation is defined for the 3046 SUPAECAPolicyRuleComposite class, which is defined below. 3048 6.4.3.2.2.1. The Aggregation "SUPAECAPolicyRules" 3050 This is a mandatory aggregation that defines the set of 3051 SUPAECAPolicyRule objects (i.e., instances of either the 3052 SUPAECAPolicyRuleAtomic or SUPAECAPolicyRuleComposite classes) 3053 that are contained in this particular SUPAECAPolicyRuleComposite 3054 object instance. The semantics of this aggregation are defined in 3055 the SUPAECAPolicyRuleDetail association class. 3057 6.4.3.2.2.2. The Association Class "SUPAECAPolicyRuleDetail" 3059 This is a mandatory association class, and defines the semantics 3060 of the SUPAECAPolicyRules aggregation. This enables the 3061 attributes and relationships of the SUPAECAPolicyRuleDetail 3062 class to be used to constrain which SUPAECAPolicyRule objects 3063 can be aggregated by this particular SUPAPolicyComposite object 3064 instance. Attributes will be added to this class at a later time. 3066 6.5. SUPAPolicyStatement Subclasses 3068 Section 5.5.2 defines a common subclass of SUPAPolicyStatement, 3069 called SUPAEncodedClause, which any SUPAPolicy (rule or predicate) 3070 can use. This section describes another specialization of the 3071 GPIM SUPAPolicyStatement class for use in constructing (only) 3072 SUPAECAPolicyRule objects. 3074 The SUPAPolicyStatement class, and its subclasses, are based on 3075 similar classes in [2]. 3077 6.5.1. Designing SUPAPolicyStatements Using SUPABooleanClauses 3079 A SUPABooleanClause specializes a SUPAPolicyClause, and defines a 3080 Boolean statement consisting of a standard structure in the form 3081 of a PolicyVariable, a PolicyOperator, and a PolicyValue. This 3082 design is based on the DEN-ng model [2]. For example, this enables 3083 the following Boolean clause to be defined: 3085 Foo >= Bar AND Baz 3087 where Foo is a PolicyVariable, >= is a PolicyOperator, and Bar is 3088 a PolicyValue. Note that in this approach, each of these three 3089 terms (i.e., the PolicyVariable, PolicyOperator, and PolicyValue) 3090 are subclasses of the SUPAPolicyTerm class, which is defined in 3091 Section 5.8). This enables the EPRIM, in conjunction with the 3092 GPIM, to be used as a reusable class library. This encourages 3093 interoperability, since each element of the clause is itself an 3094 object defined by SUPA. 3096 The addition of a negation in the above statement is provided by 3097 the supaTermIsNegated Boolean attribute in the SUPAPolicyTerm 3098 class. An entire clause is indicated as negated using the 3099 supaBoolIsNegated Boolean attribute in the SUPABooleanClause class. 3101 A PolicyStatement is in Conjunctive Normal Form (CNF) if it is a 3102 conjunction (i.e., a sequence of ANDed terms), where each term is a 3103 disjunction (i.e., a sequence of ORed terms). Every statement that 3104 consists of a combination of AND, OR, and NOT operators can be 3105 written in CNF. 3107 A PolicyStatement is in Disjunctive Normal Form (DNF) if it is a 3108 disjunction (i.e., a sequence of ORed terms), where each term is a 3109 conjunction (i.e., a sequence of ANDed terms). Every statement that 3110 consists of a combination of AND, OR, and NOT operators can be 3111 written in DNF. 3113 The supaBoolISCNF Boolean attribute of the SUPABooleanClause class 3114 is TRUE if this SUPABooleanClause is in CNF, and FALSE otherwise. 3116 The construction of more complex clauses, which consist of a set 3117 of simple clauses in conjunctive or disjunctive normal form (as 3118 shown in the above example), is provided by using the composite 3119 pattern [3] to construct two subclasses of SUPABooleanClause. 3120 These are called SUPABooleanClauseAtomic and 3121 SUPABooleanClauseComposite, and are defined in Sections 6.5.2.1 and 3122 6.5.2.2, respectively. This enables instances of either a 3123 SUPABooleanClauseAtomic and/or a SUPABooleanClauseComposite to be 3124 aggregated into a SUPABooleanClauseComposite object. 3126 6.5.2. The Abstract Class"SUPABooleanClause" 3128 This is a mandatory abstract class that defines a clause as the 3129 following three-tuple: 3131 {PolicyVariable, PolicyOperator, PolicyValue} 3133 The composite pattern [3] is used in order to construct complex 3134 Boolean clauses from a set of SUPABooleanClause objects. This is 3135 why SUPABooleanClause is defined to be abstract - only instances 3136 of the SUPABooleanAtomic and/or SUPABooleanComposite classes can 3137 be used to construct a SUPABooleanClause. 3139 SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both 3140 inherit from SUPAECAPolicyRule. This means that they are both 3141 a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRules 3142 aggregation enables a particular SUPAECAPolicyRuleComposite 3143 object to aggregate both SUPAECAPolicyRuleComposite as well as 3144 SUPAECAPolicyRuleAtomic objects. In contrast, a 3145 SUPAECAPolicyRuleAtomic can NOT aggregate either a 3146 SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. 3148 The advantage of a SUPABooleanClause is that it is formed entirely 3149 from SUPAPolicy objects. This enhances both reusability as well as 3150 interoperability. Since this involves compositing a number of 3151 objects, data model implementations MAY optimize a 3152 SUPABooleanClause according to their application-specific needs 3153 (e.g., by flattening the set of classes that make up a 3154 SUPABooleanClause object into a single object). 3156 Figure 13 below shows the composite pattern applied to the 3157 SUPABooleanClause class. 3159 1..n +-------------------+ 3160 \| | 3161 +--------------- + SUPABooleanClause | 3162 | /| | 3163 | +--------+----------+ 3164 | / \ 3165 | HasSUPABooleanClauses I 3166 | I 3167 | I 3168 | +----------------+---------+ 3169 / \ I I 3170 A I I 3171 0..1 \ / I I 3172 +-------+--------+---------+ +-----------+-----------+ 3173 |SUPABooleanClauseComposite| |SUPABooleanClauseAtomic| 3174 +--------------------------+ +-----------------------+ 3176 Figure 13. The Composite Pattern Applied to a SUPABooleanClause 3178 6.5.2.1. SUPABooleanClause Attributes 3180 The following sections define attributes of a SUPABooleanClause. 3182 6.5.2.1.1. The Attribute "supaBoolIsNegated" 3184 This is a mandatory Boolean attribute. If the value of this 3185 attribute is TRUE, then this SUPABooleanClause is negated. 3187 6.5.2.1.2. The Attribute "supaPolStmtBindValue" 3189 This is an optional non-zero integer attribute, and defines the 3190 order in which terms bind to a clause. For example, the Boolean 3191 statement "((A AND B) OR (C AND NOT (D or E))) has the following 3192 binding order: terms A and B have a bind value of 1; term C has a 3193 binding value of 2, and terms D and E have a binding value of 3. 3195 6.5.2.2. SUPABooleanClause Relationships 3197 The following subsections define the relationships of a 3198 SUPABooleanClause. 3200 6.5.2.2.1. The Relationship "SUPABooleanClauses" 3202 This is a mandatory aggregation that defines the set of 3203 SUPABooleanClauses that are aggregated by this 3204 SUPABooleanClauseComposite. This will either form a complete 3205 SUPABooleanClause from multiple clauses (which can be made up of 3206 SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite object 3207 instances) or define another level in the SUPABooleanClause object 3208 hierarchy. 3210 The multiplicity of this relationship is 0..1 on the aggregate 3211 (SUPABooleanClauseComposite) side, and 1..n on the part 3212 (SUPABooleanClause) side. This means that one or more 3213 SUPABooleanClauses are aggregated and used to define this 3214 SUPABooleanClauseComposite object. The 0..1 cardinality on the 3215 SUPABooleanClauseComposite side is necessary to enable 3216 SUPABooleanClauses to exist (e.g., in a PolicyRepository) before 3217 they are used by a SUPABooleanClauseComposite. The semantics of 3218 this aggregation is defined by the SUPABooleanClauseDetail 3219 association class. 3221 6.5.2.2.1.1. The Association Class "SUPABooleanClauseDetail" 3223 This is a mandatory association class that defines the semantics 3224 of the SUPABooleanClauses aggregation. This enables the 3225 attributes and relationships of the SUPABooleanClauseDetail 3226 class to be used to constrain which SUPABooleanClause objects 3227 can be aggregated by this particular SUPABooleanClauseComposite 3228 object instance. Attributes will be added to this class at a 3229 later time. 3231 6.5.3. SUPABooleanClause Subclasses 3233 SUPABooleanClause defines two subclasses, as shown in Figure 13. 3234 They are both described in the following subsections. 3236 6.5.3.1. The Abstract Class "SUPABooleanClauseAtomic" 3238 This is a mandatory concrete class that represents a 3239 SUPABooleanClause that can operate as a single, stand-alone, 3240 manageable object. Put another way, a SUPABooleanClauseAtomic 3241 object can NOT be modeled as a set of hierarchical clauses; if 3242 this functionality is required, then a SUPABooleanClauseComposite 3243 object must be used. 3245 SUPAPolicyAtomic was abstracted from DEN-ng [2], and a version of 3246 this class is in the process of being added to the policy 3247 framework defined in the TM Forum ZOOM model [5]. 3249 No attributes are currently defined for the SUPABooleanClauseAtomic 3250 class. Its primary purpose is to aggregate SUPAPolicyVariable, 3251 SUPAPolicyOperator, and SUPAPolicyValue objects to form a complete 3252 SUPABoolean clause. As such, this class is defined as abstract to 3253 simplify data model optimization and mapping. 3255 6.5.3.2. The Abstract Class "SUPABooleanClauseComposite" 3257 This is a mandatory concrete class that represents a 3258 SUPABooleanClause that can operate as a hierarchy of PolicyClause 3259 objects, where the hierarchy contains instances of a 3260 SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite 3261 object. Each of the SUPABooleanClauseAtomic and 3262 SUPABooleanClauseComposite objects, including the outermost 3263 SUPABooleanClauseComposite object, are separately manageable. More 3264 importantly, the SUPABooleanClauseComposite object can aggregate 3265 any SUPABooleanClause subclass. Hence, it can be used to form 3266 hierarchies of SUPABooleanClauses. 3268 SUPABooleanClauseComposite was abstracted from DEN-ng [2], and a 3269 version of this class is in the process of being added to the 3270 policy framework defined in the TM Forum ZOOM model [5]. 3272 6.5.3.2.1. SUPABooleanClauseComposite Attributes 3274 A single attributes is currently defined for the 3275 SUPABooleanClauseComposite class, and is described in the 3276 following subsection. 3278 6.5.3.2.1.1. The Attribute "supaBoolClauseIsCNF" 3280 This is a mandatory Boolean attribute. If its value is true, then 3281 this SUPABooleanClauseComposite is defined in Conjunctive Normal 3282 Form (i.e., and AND of ORs). Otherwise, it is defined in 3283 Disjunctive Normal Form (i.e., and OR of ANDs). 3285 6.6. The Abstract Class "SUPAECAComponent" 3287 This is a mandatory abstract class that defines three subclasses, 3288 one each for the event, condition, and action portions of a 3289 SUPAECAPolicyRule. They are called SUPAEvent, SUPACondition, and 3290 SUPAAction, respectively. Its primary purpose is to serve as a 3291 convenient aggregation point, and thus has two uses: 3293 1. This enables a single aggregation (SUPAECAComponentsInTerms, 3294 see section 6.6.2.1) to be used to specify which object 3295 instances of which SUPAPolicyTerm subclasses are contained 3296 by a particular SUPAECAComponent object instance. Otherwise, 3297 a set of three aggregations would be required. 3298 2. This enables a single class (SUPAECAComponentsInTermsDetail, 3299 see section 6.6.2.1.1) to be used as a superclass to define 3300 which the specific semantics required by this combination 3301 of SUPAPolicyTerm and SUPAECAComponent subclasses. 3303 6.6.1. SUPAECAComponent Attributes 3305 No attributes are currently defined for this class. 3307 6.6.2. SUPAECAComponent Relationships 3309 A single aggregation is defined for this class, as specified 3310 below. 3312 6.6.2.1. The Aggregation "SUPAECAComponentsInTerms" 3314 This is a mandatory aggregation that defines the set of 3315 SUPAPolicyTerms that are aggregated by this SUPAECAComponent. 3316 This enables complex combinations of SUPAPolicyTerms to be 3317 defined as SUPAEvents, SUPAConditions, or SUPAActions, which 3318 increases reusability. It also simplifies forming more complex 3319 Boolean clauses as combinations of SUPAEvents, SUPAConditions, or 3320 SUPAActions. 3322 The multiplicity of this relationship is 0..1 on the aggregate 3323 (SUPAECAComponent) side, and 0..n on the part (SUPAPolicyTerm) 3324 side. This means that this aggregation is completely optional. 3325 However, if it is instantiated, then zero or more SUPAPolicyTerms 3326 can be aggregated by a particular SUPAECAComponent. Similarly, a 3327 given SUPAPolicyTerm can be used by zero or more SUPAECAComponents. 3328 The 0..1 cardinality on the SUPAECAComponent side is necessary to 3329 enable SUPAPolicyTerm objects to exist (e.g., in a 3330 PolicyRepository) before they are used by a SUPAECAComponent. The 3331 semantics of this aggregation is defined by the 3332 SUPAECAComponentHasTermDetail association class. 3334 6.6.2.1.1. The Association Class "SUPAECAComponentsInTermDetail" 3336 This is a mandatory association class that defines the semantics 3337 of the SUPAECAComponentsInTerms aggregation. This enables the 3338 attributes and relationships of the SUPAECAComponentsInTermDetail 3339 class to be used to constrain which SUPAPolicyTerm objects can be 3340 aggregated by this particular SUPAECAComponent object instance. 3341 Attributes will be added to this class at a later time. 3343 6.6.3. SUPAECAComponent Subclasses 3345 There are three concrete subclasses of SUPAECAComponent; they are 3346 described in the following subsections. 3348 6.6.3.1. The Concrete Class"SUPAEvent" 3350 THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT. 3352 6.6.3.2. The Concrete Class"SUPACondition" 3354 THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT. 3356 6.6.3.3. The Concrete Class"SUPAAction" 3358 THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT. 3360 7. SUPA Logic Statement Information Model 3362 This section defines the classes, attributes, and relationships of 3363 the SUPA Logic Statement Information Model (LSIM). 3365 7.1. Overview 3367 A Goal policy rule (also called a declarative policy rule, or an 3368 intent-based policy rule) is a declarative statement that defines 3369 what the policy should do, but not how to implement the policy. In 3370 this draft, such rules are called SUPA Logic Statements. 3372 This Section, and the following Sections, will be finished in the 3373 next version of this document. 3375 7.2. Constructing a SUPAPLStatement 3377 This section will be finished in the next version of this document. 3379 7.3. Working With SUPAPLStatements 3381 This section will be finished in the next version of this document. 3383 7.4. The Abstract Class "SUPALogicClause" 3385 A SUPALogicStatement is an abstract class that represents 3386 declarative (also called intent-based) policies. A 3387 SUPALogicStatement MUST contain at least one SUPAPolicyStatement. 3388 Such policies define a goal to be achieved, or a set of actions to 3389 take, but do not prescribe how to achieve the goal or execute the 3390 actions. This differentiates it from a SUPAECAPolicyRule, which 3391 explicitly defines what triggers the evaluation of the 3392 SUPAECAPolicyRule, what conditions must be satisfied in order to 3393 execute the actions of the SUPAECAPolicyRule, and what actions to 3394 execute. 3396 This document defines two forms of a SUPALogicStatements. The first 3397 uses Propositional Logic (PL, see Section 3.2.4.2), while the 3398 second uses First-Order Logic (FOL, see Section 3.2.4.3). 3400 Note that this document does not refer to a SUPALogicStatement as 3401 a "rule", since both types of SUPALogicStatements defined in this 3402 document are technically not "rules". Rather, they are types of 3403 zero-order and first-order logic statements. 3405 If the SUPALogicStatement is expressed in PL, then it MUST consist 3406 of only the propositional connectives (i.e., negation, conjunction, 3407 disjunction, implication, and bi-implication (see Section 3.2.4.1). 3408 Furthermore, statements in a PL are limited to simple declarative 3409 propositions that MUST NOT use quantified variable or predicates. 3411 If the SUPALogicStatement is expressed in FOL, then it MUST consist 3412 of a set of logical predicates (i.e., a Boolean-valued function). 3413 The predicate can use all propositional connectives as well as two 3414 additional quantifiers (i.e., the universal quantifier and the 3415 existential quantifier). 3417 A logical predicate MUST consist of a head clause, and MAY also 3418 contain a body clause. This enables the semantics of a 3419 SUPALogicStatement to be clearly differentiated from the semantics 3420 of other types of SUPAPolicies that use SUPAPolicyStatements (and 3421 other parts of the SPGIM), such as SUPAECAPolicyRules. While in 3422 principle higher order logics can be defined, this document is 3423 limited to defining a SUPALogicStatement using either PL or FOL. 3425 When implemented in an information model, each PL or FOL statement 3426 MUST be defined as objects (i.e., a subclass of the 3427 SUPALogicStatement class; see Section 7). When an FOL statement is 3428 implemented in an information model, both the head and body clauses 3429 MUST be defined as objects (or sets of objects). However, a data 3430 model MAY map either a PL statement or an FOL statement to a more 3431 efficient form (e.g., by flattening the head and body objects into 3432 a single object). 3434 7.5. The Abstract Class "SUPAPLStatement" 3436 This section will be finished in the next version of this document. 3438 7.5.1. SUPAPLStatement Attributes 3440 This section will be finished in the next version of this document. 3442 7.5.2. SUPAPLStatement Relationships 3444 This section will be finished in the next version of this document. 3446 7.5.3. SUPAPLStatement Subclasses 3448 This section will be finished in the next version of this document. 3450 7.5.3.1. The Concrete Class "SUPAArgument" 3452 7.5.3.2. The Concrete Class "SUPAPLPremise" 3454 7.5.3.3. The Concrete Class "SUPAPLConclusion" 3456 7.6. Constructing a SUPAFOLStatement 3458 7.7. Working With SUPAFOLStatements 3460 7.7.1. SUPAFOLStatement Attributes 3462 7.7.2. SUPAFOLStatement Relationships 3464 7.7.3. SUPAFOLStatement Subclasses 3466 7.7.3.1. The Concrete Class "SUPAGoalHead" 3468 7.7.3.2. The Concrete Class "SUPAGoalBody" 3470 7.8. Combining Different Types of SUPAFOLStatements 3471 8. Examples 3473 8.1. SUPAECAPolicyRule Examples 3475 8.2. SUPALogicStatement Examples 3477 8.3. Mixing SUPAECAPolicyRules and SUPALogicStatements 3479 9. Security Considerations 3481 This will be defined in the next version of this document. 3483 10. IANA Considerations 3485 This document has no actions for IANA. 3487 11. Acknowledgments 3489 This document has benefited from reviews, suggestions, comments 3490 and proposed text provided by the following members, listed in 3491 alphabetical order: Andy Bierman, Bob Natale, Fred Feisullin, 3492 Liu (Will) Shucheng, Marie-Jose Montpetit. 3494 12. References 3496 This section defines normative and informative references for this document. 3498 12.1. Normative References 3500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3501 Requirement Levels", BCP 14, RFC 2119, March 1997. 3503 [RFC3060] Moore, B., Ellesson, E., Strassner, J., Westerinen, 3504 A., "Policy Core Information Model -- Version 1 3505 Specification", RFC 3060, February 2001 3507 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 3508 Scherling, M., Quinn, B., Herzog, S., Huynh, A., 3509 Carlson, M., Perry, J., Waldbusser, S., "Terminology 3510 for Policy-Based Management", RFC 3198, November, 2001 3512 [RFC3460] Moore, B., ed., "Policy Core Information Model (PCIM) 3513 Extensions, RFC 3460, January 2003 3515 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for 3516 the Network Configuration Protocol (NETCONF)", 3517 RFC 6020, October 2010. 3519 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 3520 October 2010. 3522 12.2. Informative References 3524 [1] Strassner, J., "Policy-Based Network Management", 3525 Morgan Kaufman, ISBN 978-1558608597, Sep 2003 3527 [2] Strassner, J., ed., "The DEN-ng Information Model", 3528 add stable URI 3530 [3] Riehle, D., "Composite Design Patterns", Proceedings 3531 of the 1997 Conference on Object-Oriented Programming 3532 Systems, Languages and Applications (OOPSLA '97). 3533 ACM Press, 1997. Page 218-228 3535 [4] DMTF, CIM Schema, v2.44, 3536 http://dmtf.org/standards/cim/cim_schema_v2440 3538 [5] Strassner, J., ed., "ZOOM Policy Architecture and 3539 Information Model Snapshot", TR235, part of the 3540 TM Forum ZOOM project, October 26, 2014 3542 [6] TM Forum, "Information Framework (SID), GB922 and 3543 associated Addenda, v14.5, 3544 https://www.tmforum.org/information-framework-sid/ 3546 [7] Liskov, B.H., Wing, J.M., "A Behavioral Notion of 3547 subtyping", ACM Transactions on Programming languages 3548 and Systems 16 (6): 1811 - 1841, 1994 3550 [8] Klyus, M., Strassner, J., editors, "SUPA Proposition", 3551 IETF Internet draft, draft-klyus-supa-proposition-01, 3552 July 2015 3554 [9] ISO/IEC 10746-3 (also ITU-T Rec X.903), "Reference 3555 Model Open Distributed Processing Architecture", 3556 April 20, 2010 3558 Authors' Addresses 3560 John Strassner 3561 Huawei Technologies 3562 2330 Central Expressway 3563 Santa Clara, CA 95138 USA 3564 Email: john.sc.strassner@huawei.com