draft-ietf-supa-generic-policy-info-model-02.txt   draft-ietf-supa-generic-policy-info-model-03.txt 
Network Working Group J. Strassner Network Working Group J. Strassner
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Standard Track J. Halpern Intended status: Standard Track J. Halpern
Expires: July 20, 2017 S. van der Meer Expires: November 30, 2017 S. van der Meer
Ericsson Ericsson
January 18, 2017 May 30, 2017
Generic Policy Information Model for Generic Policy Information Model for
Simplified Use of Policy Abstractions (SUPA) Simplified Use of Policy Abstractions (SUPA)
draft-ietf-supa-generic-policy-info-model-02 draft-ietf-supa-generic-policy-info-model-03
Abstract Abstract
This document defines an information model for representing This document defines an information model for representing
policies using a common extensible framework that is independent policies using a common extensible framework that is independent
of language, protocol, repository. It is also independent of the of language, protocol, repository. It is also independent of the
level of abstraction of the content and meaning of a policy. level of abstraction of the content and meaning of a policy.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
This Internet-Draft will expire on July 20, 2017. This Internet-Draft will expire on November 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
*** Note: this is out of date, will be fixed in next version ***
1. Overview ....................................................... 9 1. Overview ....................................................... 9
1.1. Introduction .............................................. 9 1.1. Introduction .............................................. 9
1.2. Changes Since Version -03 ................................ 11 1.2. Changes Since Version -03 ................................ 11
2. Conventions Used in This Document ............................. 11 2. Conventions Used in This Document ............................. 11
3. Terminology ................................................... 12 3. Terminology ................................................... 12
3.1. Acronyms ................................................. 12 3.1. Acronyms ................................................. 12
3.2. Definitions .............................................. 12 3.2. Definitions .............................................. 12
3.2.1. Core Terminology .................................... 12 3.2.1. Core Terminology .................................... 12
3.2.1.1. Information Model .............................. 12 3.2.1.1. Information Model .............................. 12
skipping to change at page 3, line 4 skipping to change at page 2, line 49
3.3. Symbology ................................................ 18 3.3. Symbology ................................................ 18
3.3.1. Inheritance ......................................... 18 3.3.1. Inheritance ......................................... 18
3.3.2. Association ......................................... 19 3.3.2. Association ......................................... 19
3.3.3. Aggregation ......................................... 19 3.3.3. Aggregation ......................................... 19
3.3.4. Composition ......................................... 19 3.3.4. Composition ......................................... 19
3.3.5. Association Class ................................... 19 3.3.5. Association Class ................................... 19
3.3.6. Abstract vs. Concrete Classes ....................... 20 3.3.6. Abstract vs. Concrete Classes ....................... 20
4. Policy Abstraction Architecture ............................... 21 4. Policy Abstraction Architecture ............................... 21
4.1. Motivation ............................................... 22 4.1. Motivation ............................................... 22
4.2. SUPA Approach ............................................ 23 4.2. SUPA Approach ............................................ 23
4.2.1. Design Patterns ..................................... 23
4.2.1.1. Composite Pattern .............................. 24
4.2.1.2. Decorator Pattern .............................. 24
4.2.2. Association Classes ................................. 26
Table of Contents (continued) Table of Contents (continued)
4.3. SUPA Generic Policy Information Model Overview............ 23 4.3. SUPA Generic Policy Information Model Overview............ 27
4.3.1. SUPAPolicyObject .................................... 25 4.3.1. SUPAPolicyObject .................................... 29
4.3.2. SUPAPolicyStructure ................................. 26 4.3.2. SUPAPolicyStructure ................................. 30
4.3.3. SUPAPolicyComponentStructure ........................ 26 4.3.3. SUPAPolicyComponentStructure ........................ 30
4.3.4. SUPAPolicyClause .................................... 27 4.3.4. SUPAPolicyClause .................................... 31
4.3.5. SUPAPolicyComponentDecorator ........................ 27 4.3.5. SUPAPolicyClauseComponentDecorator .................. 31
4.3.6. SUPAPolicyTarget .................................... 28 4.3.6. SUPAPolicyTarget .................................... 32
4.3.7. SUPAPolicySource .................................... 28 4.3.7. SUPAPolicySource .................................... 32
4.4. The Design of the GPIM ................................... 28 4.4. The Design of the GPIM ................................... 32
4.4.1. Structure of Policies ............................... 29 4.4.1. Structure of Policies ............................... 33
4.4.2. Representing an ECA Policy Rule ..................... 30 4.4.2. Representing an ECA Policy Rule ..................... 34
4.4.3. Creating SUPA Policy Clauses ........................ 33 4.4.3. Creating SUPA Policy Clauses ........................ 37
4.4.4. Creating SUPAPolicyClauses .......................... 36 4.4.4. Creating SUPAPolicyClauses .......................... 41
4.4.5. SUPAPolicySources ................................... 37 4.4.5. SUPAPolicySources ................................... 42
4.4.6. SUPAPolicyTargets ................................... 39 4.4.6. SUPAPolicyTargets ................................... 43
4.4.7. SUPAPolicyMetadata .................................. 39 4.4.7. SUPAPolicyMetadata .................................. 43
4.4.7.1. Motivation ..................................... 39 4.4.7.1. Motivation ..................................... 44
4.4.7.2. Design Approach ................................ 40 4.4.7.2. Design Approach ................................ 45
4.4.7.2.1. Policies and Actors ....................... 42 4.4.7.2.1. Policies and Actors ....................... 46
4.4.7.2.2. Deployment vs. Execution of Policies ...... 43 4.4.7.2.2. Deployment vs. Execution of Policies ...... 47
4.4.7.2.3. Using SUPAMetadata for Policy Deployment 4.4.7.2.3. Using SUPAMetadata for Policy Deployment
and Execution ............................. 43 and Execution ............................. 47
4.4.7.3. Structure of SUPAPolicyMetadata ................ 44 4.4.7.3. Structure of SUPAPolicyMetadata ................ 48
4.5. Advanced Features ........................................ 47 5. GPIM Model .................................................... 52
4.5.1. Policy Grouping ..................................... 47 5.1. Overview ................................................. 52
4.5.2. Policy Rule Nesting ................................. 47 5.2. The Abstract Class "SUPAPolicyObject" .................... 53
5. GPIM Model .................................................... 48 5.2.1. SUPAPolicyObject Attributes ......................... 54
5.1. Overview ................................................. 48 5.2.1.1. Object Identifiers ............................. 54
5.2. The Abstract Class "SUPAPolicyObject" .................... 49 5.2.1.2. The Attribute "supaPolObjIDContent" ............ 55
5.2.1. SUPAPolicyObject Attributes ......................... 50 5.2.1.3. The Attribute "supaPolObjIDEncoding" ........... 55
5.2.1.1. Object Identifiers ............................. 50 5.2.1.4. The Attribute "supaPolicyDescription" .......... 55
5.2.1.2. The Attribute "supaPolObjIDContent" ............ 51 5.2.1.5. The Attribute "supaPolicyName" ................. 55
5.2.1.3. The Attribute "supaPolObjIDEncoding" ........... 51 5.2.2. SUPAPolicy Relationships ............................ 56
5.2.1.4. The Attribute "supaPolicyDescription" .......... 51 5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 56
5.2.1.5. The Attribute "supaPolicyName" ................. 51
5.2.2. SUPAPolicy Relationships ............................ 52
5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 52
5.2.2.2. The Association Class 5.2.2.2. The Association Class
"SUPAHasPolicyMetadataDetail" .................. 52 "SUPAHasPolicyMetadataDetail" .................. 56
5.3. The Abstract Class "SUPAPolicyStructure" ................. 52 5.3. The Abstract Class "SUPAPolicyStructure" ................. 56
5.3.1. SUPAPolicyStructure Attributes ...................... 53 5.3.1. SUPAPolicyStructure Attributes ...................... 57
5.3.1.1. The Attribute "supaPolAdminStatus" ............. 53 5.3.1.1. The Attribute "supaPolAdminStatus" ............. 57
5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 53 5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 57
5.3.1.3. The Attribute "supaPolDeployStatus" ............ 54 5.3.1.3. The Attribute "supaPolDeployStatus" ............ 58
5.3.1.4. The Attribute "supaPolExecFailStrategy" ........ 54 5.3.1.4. The Attribute "supaPolExecFailStrategy" ........ 58
5.3.2. SUPAPolicyStructure Relationships ................... 59
5.3.2.1. The Aggregation "SUPAHasPolicySource" .......... 59
5.3.2.2. The Association Class
"SUPAHasPolicySourceDetail" .................... 59
5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" . 59
5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" ....... 59
Table of Contents (continued) Table of Contents (continued)
5.3.2. SUPAPolicyStructure Relationships ................... 55 5.3.2.3. The Aggregation "SUPAHasPolicyTarget" .......... 59
5.3.2.1. The Aggregation "SUPAHasPolicySource" .......... 55
5.3.2.2. The Association Class
"SUPAHasPolicySourceDetail" .................... 55
5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" . 55
5.3.2.2.2. The Attribute "supaPolSrcIsTrusted" ....... 56
5.3.2.3. The Aggregation "SUPAHasPolicyTarget" .......... 56
5.3.2.4. The Association Class 5.3.2.4. The Association Class
"SUPAHasPolicyTargetDetail" ................... 56 "SUPAHasPolicyTargetDetail" ................... 60
5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" . 56 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" . 60
5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" ....... 56 5.3.2.4.2. The Attribute "supaPolTgtIsEnabled" ....... 60
5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" . 57 5.3.2.5. The Association "SUPAHasPolExecFailTakeAction" . 60
5.3.2.6. The Association Class 5.3.2.6. The Association Class
"SUPAHasPolExecFailTakeActionDetail" ........... 57 "SUPAHasPolExecFailTakeActionDetail" ........... 61
5.3.2.6.1. The Attribute 5.3.2.6.1. The Attribute
"supaPolExecFailActionEncoding" ........... 57 "supaPolExecFailActionEncoding" ........... 61
5.3.2.6.2. The Attribute 5.3.2.6.2. The Attribute
"supaPolExecFailActionName[1..n]" ......... 58 "supaPolExecFailActionName[1..n]" ......... 62
5.3.2.7. The Aggregation "SUPAHasPolicyClause" .......... 58 5.3.2.7. The Aggregation "SUPAHasPolicyClause" .......... 62
5.3.2.8. The Association Class 5.3.2.8. The Association Class
"SUPAHasPolicyClauseDetail" .................... 58 "SUPAHasPolicyClauseDetail" .................... 63
5.4. The Abstract Class "SUPAPolicyComponentStructure" ........ 59 5.4. The Abstract Class "SUPAPolicyComponentStructure" ........ 63
5.4.1. SUPAPolicyComponentStructure Attributes ............. 59 5.4.1. SUPAPolicyComponentStructure Attributes ............. 63
5.4.2. SUPAPolicyComponentStructure Relationships .......... 59 5.4.2. SUPAPolicyComponentStructure Relationships .......... 63
5.5. The Abstract Class "SUPAPolicyClause" .................... 59 5.5. The Abstract Class "SUPAPolicyClause" .................... 64
5.5.1. SUPAPolicyClause Attributes ......................... 60 5.5.1. SUPAPolicyClause Attributes ......................... 65
5.5.1.1. The Attribute "supaPolClauseDeployStatus" ...... 60 5.5.1.1. The Attribute "supaPolClauseDeployStatus" ...... 65
5.5.2. SUPAPolicyClause Relationships ...................... 61 5.5.2. SUPAPolicyClause Relationships ...................... 65
5.6. The Concrete Class "SUPAEncodedClause" ................... 61 5.5.2.1. The Aggregation "SUPAPolicyClauseHasDecorator" . 66
5.6.1. SUPAEncodedClause Attributes ........................ 61 5.5.2.2. The Association Class
5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 61 "SUPAPolicyClauseHasDecoratorDetail" ........... 66
5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 61 5.5.2.2.1. The Attribute
5.6.1.3. The Attribute "supaEncodedClauseLanguage" ...... 62 "supaPolClauseDecConstraintEncoding" ...... 66
5.6.1.4. The Attribute "supaEncodedClauseResponse" ...... 62 5.5.2.2.2. The Attribute
5.6.2. SUPAEncodedClause Relationships ..................... 62 "supaPolClauseDecConstraint[0..n]" ........ 66
5.7. The Abstract Class "SUPAPolicyComponentDecorator" ........ 62 5.6. The Concrete Class "SUPAEncodedClause" ................... 67
5.7.1. The Decorator Pattern ............................... 63 5.6.1. SUPAEncodedClause Attributes ........................ 67
5.7.2. SUPAPolicyComponentDecorator Attributes ............. 64 5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 68
5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 65 5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 68
5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 65 5.6.1.3. The Attribute "supaEncodedClauseLanguage" ...... 68
5.7.3. SUPAPolicyComponentDecorator Relationships .......... 65 5.6.1.4. The Attribute "supaEncodedClauseResponse" ...... 69
5.7.3.1. The Aggregation 5.6.2. SUPAEncodedClause Relationships ..................... 69
"SUPAHasDecoratedPolicyComponent" .............. 66 5.7. The Abstract Class "SUPAPolicyClauseComponentDecorator ... 69
5.7.3.2. The Association Class 5.7.1. SUPAPolicyClauseComponentDecorator Attributes ....... 70
"SUPAHasDecoratedPolicyComponentDetail" ........ 66 5.7.1.1. The Attribute "supaPolClauseConstraintEncoding" 70
5.7.3.2.1. The Attribute 5.7.1.2. The Attribute "supaPolClauseConstraint[0..n]" .. 71
"supaDecoratedConstraintEncoding" ......... 66 5.7.2. SUPAPolicyClauseComponentDecorator Relationships .... 71
5.7.3.2.2. The Attribute 5.7.3. Illustration of Constraints in the Decorator Pattern 71
"supaDecoratedConstraint[0..n]" ........... 67 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 72
5.8.1. SUPAPolicyTerm Attributes ........................... 73
5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 73
5.8.2. SUPAPolicyTerm Relationships ........................ 73
Table of Contents (continued) Table of Contents (continued)
5.7.4. Illustration of Constraints in the Decorator Pattern 67 5.9. The Concrete Class "SUPAPolicyVariable" .................. 74
5.8. The Abstract Class "SUPAPolicyTerm" ...................... 68 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 74
5.8.1. SUPAPolicyTerm Attributes ........................... 69 5.9.2. SUPAPolicyVariable Attributes ....................... 74
5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 69 5.9.2.1. The Attribute "supaPolVarName" ................. 74
5.8.2. SUPAPolicyTerm Relationships ........................ 69 5.9.3. SUPAPolicyVariable Relationships .................... 75
5.9. The Concrete Class "SUPAPolicyVariable" .................. 69 5.10. The Concrete Class "SUPAPolicyOperator" ................. 75
5.9.1. Problems with the RFC3460 Version of PolicyVariable . 70 5.10.1. Problems with the RFC3460 Version .................. 75
5.9.2. SUPAPolicyVariable Attributes ....................... 70 5.10.2. SUPAPolicyOperator Attributes ...................... 75
5.9.2.1. The Attribute "supaPolVarName" ................. 70 5.10.2.1. The Attribute "supaPolOpType" ................. 75
5.9.3. SUPAPolicyVariable Relationships .................... 70 5.10.3. SUPAPolicyOperator Relationships ................... 76
5.10. The Concrete Class "SUPAPolicyOperator" ................. 70 5.11. The Concrete Class "SUPAPolicyValue" .................... 76
5.10.1. Problems with the RFC3460 Version .................. 71 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 77
5.10.2. SUPAPolicyOperator Attributes ...................... 71 5.11.2. SUPAPolicyValue Attributes ......................... 77
5.10.2.1. The Attribute "supaPolOpType" ................. 71 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 77
5.10.3. SUPAPolicyOperator Relationships ................... 71 5.11.2.2. The Attribute "supaPolValEncoding" ............ 77
5.11. The Concrete Class "SUPAPolicyValue" .................... 72 5.11.3. SUPAPolicyValue Relationships ...................... 78
5.11.1. Problems with the RFC3460 Version of PolicyValue ... 72 5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 78
5.11.2. SUPAPolicyValue Attributes ......................... 72 5.12.1. SUPAGenericDecoratedComponent Attributes ........... 78
5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 72
5.11.2.2. The Attribute "supaPolValEncoding" ............ 73
5.11.3. SUPAPolicyValue Relationships ...................... 73
5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 73
5.12.1. SUPAGenericDecoratedComponent Attributes ........... 74
5.12.1.1. The Attribute 5.12.1.1. The Attribute
"supaVendorDecoratedCompContent[0..n]" ........ 74 "supaGenericDecoratedCompContent[0..n]" ....... 79
5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 74 5.12.1.2. The Attribute
5.12.2. SUPAGenericDecoratedComponent Relationships ........ 74 "supaGenericDecoratedCompEncoding" ............ 79
5.13. The Concrete Class "SUPAPolicyCollection" ............... 75 5.12.2. SUPAGenericDecoratedComponent Relationships ........ 79
5.13.1. Motivation ......................................... 75 5.13. The Concrete Class "SUPAPolicyCollection" ............... 80
5.13.2. Solution ........................................... 75 5.13.1. Motivation ......................................... 80
5.13.3. SUPAPolicyCollection Attributes .................... 76 5.13.2. Solution ........................................... 80
5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 76 5.13.3. SUPAPolicyCollection Attributes .................... 81
5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 76 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 81
5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 76 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 81
5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 76 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 81
5.13.3.5. The Attribute "supaPolCollectionType" ......... 77 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 82
5.13.4. SUPAPolicyCollection Relationships ................. 78 5.13.3.5. The Attribute "supaPolCollectionType" ......... 82
5.14. The Concrete Class "SUPAPolicySource" .................... 78 5.13.4. SUPAPolicyCollection Relationships ................. 83
5.14.1. SUPAPolicySource Attributes ........................ 78 5.14. The Abstract Class "SUPAPolicyComponentDecorator ........ 83
5.14.2. SUPAPolicySource Relationships ..................... 78 5.14.1. SUPAPolicyComponentDecorator Attributes ............ 84
5.15. The Concrete Class "SUPAPolicyTarget" ................... 78 5.14.1.1. The Attribute "supaPolCompConstraintEncoding" . 84
5.15.1. SUPAPolicyTarget Attributes ........................ 79 5.14.1.2. The Attribute "supaPolCompConstraint[0..n]" ... 85
5.15.2. SUPAPolicyTarget Relationships ..................... 79 5.14.2. SUPAPolicyComponentDecorator Relationships ......... 85
5.14.2.1. The Aggregation
"SUPAHasDecoratedPolicyComponent" ............. 85
5.14.2.2. The Association Class
"SUPAHasDecoratedPolicyComponentDetail" ....... 85
5.14.2.1.1. The Attribute
"supaPolCompConstraintEncoding" .......... 86
5.14.2.1.2. The Attribute
"supaPolCompConstraint[0..n]" ............ 86
Table of Contents (continued) Table of Contents (continued)
5.16. The Abstract Class "SUPAPolicyMetadata" ................. 79 5.15. The Concrete Class "SUPAPolicySource" .................... 86
5.16.1. SUPAPolicyMetadata Attributes ...................... 80 5.15.1. SUPAPolicySource Attributes ........................ 86
5.16.1.1. The Attribute "supaPolMetadataDescription" .... 80 5.15.2. SUPAPolicySource Relationships ..................... 87
5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 80 5.16. The Concrete Class "SUPAPolicyTarget" ................... 87
5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 80 5.16.1. SUPAPolicyTarget Attributes ........................ 87
5.16.1.4. The Attribute "supaPolMetadataName" ........... 81 5.16.2. SUPAPolicyTarget Relationships ..................... 87
5.16.2. SUPAPolicyMetadata Relationships ................... 81 5.17. The Abstract Class "SUPAPolicyMetadata" ................. 88
5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 81 5.17.1. SUPAPolicyMetadata Attributes ...................... 89
5.16.2.2. The Association Class 5.17.1.1. The Attribute "supaPolMetadataDescription" .... 89
"SUPAHasPolicyMetadataDetail" ................. 81 5.17.1.2. The Attribute "supaPolMetadataIDContent" ...... 89
5.16.2.2.1. The Attribute 5.17.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 89
"supaPolMetadataIsApplicable" ............ 81 5.17.1.4. The Attribute "supaPolMetadataName" ........... 90
5.16.2.2.2. The Attribute 5.17.2. SUPAPolicyMetadata Relationships ................... 90
"supaPolMetadataConstraintEncoding" ...... 82 5.17.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 90
5.16.2.2.3. The Attribute 5.17.2.2. The Association Class
"supaPolMetadataConstraint[0..n]" ........ 82 "SUPAHasPolicyMetadataDetail" ................. 90
5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 82 5.17.2.2.1. The Attribute
5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 83 "supaPolMetadataConstraintEncoding" ...... 90
5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" ...... 83 5.17.2.2.2. The Attribute
5.17.1.2. The Attribute "supaPolMDValidPeriodStart" .... 83 "supaPolMetadataConstraint[0..n]" ........ 91
5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 83 5.17.2.2.3. The Attribute
5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 83 "supaPolMetadataIsApplicable" ............ 91
5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 83 5.18. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 91
5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 83 5.18.1. SUPAPolicyConcreteMetadata Attributes .............. 91
5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" .... 84 5.18.1.1. The Attribute "supaPolMDValidPeriodEnd" ...... 92
5.18.2.2. The Association Class 5.18.1.2. The Attribute "supaPolMDValidPeriodStart" .... 92
"SUPAHasMetadataDecoratorDetail" .............. 84 5.18.2. SUPAPolicyConcreteMetadata Relationships ........... 92
5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 84 5.19. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 92
5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 85 5.19.1. SUPAPolicyMetadataDecorator Attributes ............. 92
5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 85 5.19.2. SUPAPolicyMetadataDecorator Relationships .......... 92
5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 85 5.19.2.1. The Aggregation "SUPAHasMetadataDecorator" .... 92
5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 86 5.19.2.2. The Association Class
5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 86 "SUPAHasMetadataDecoratorDetail" .............. 93
5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 86 5.19.2.2.1. The Attribute
5.20.1.1. The Attribute "supaVersionMajor" .............. 87 "supaPolMetadataConstraintEncoding" ...... 93
5.20.1.2. The Attribute "supaVersionMinor" .............. 88 5.19.2.2.2. The Attribute
5.20.1.3. The Attribute "supaVersionPatch" .............. 88 "supaPolMetadataConstraint[0..n]" ........ 94
5.20.1.4. The Attribute "supaVersionPreRelease" ......... 88 5.19.2.2.3. The Attribute
5.20.1.5. The Attribute "supaVersionBuildMetadata" ...... 89 "supaPolMetadataDecIsApplicable" ......... 94
6. SUPA ECAPolicyRule Information Model .......................... 89 5.20. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 94
6.1. Overview ................................................. 89 5.20.1. SUPAPolicyAccessMetadataDef Attributes ............. 94
6.2. Constructing a SUPAECAPolicyRule ......................... 91 5.20.1.1. The Attribute "supaPolAccessPrivilegeDef" ..... 94
6.3. Working With SUPAECAPolicyRules .......................... 92 5.20.1.2. The Attribute "supaPolAccessPrivilegeModelName" 95
6.4. The Abstract Class "SUPAECAPolicyRule" ................... 93 5.20.1.3. The Attribute "supaPolAccessPrivilegeModelRef" 95
6.4.1. SUPAECAPolicyRule Attributes ........................ 95
6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 95
6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ........ 95
6.4.2. SUPAECAPolicyRule Relationships ..................... 96
Table of Contents (continued) Table of Contents (continued)
6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 96 5.21. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 96
6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 96 5.21.1. SUPAPolicyVersionMetadataDef Attributes ............ 96
6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 96 5.21.1.1. The Attribute "supaVersionMajor" .............. 97
6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 96 5.21.1.2. The Attribute "supaVersionMinor" .............. 98
6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 96 5.21.1.3. The Attribute "supaVersionPatch" .............. 98
6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 97 5.21.1.4. The Attribute "supaVersionPreRelease" ......... 98
6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 97 5.21.1.5. The Attribute "supaVersionBuildMetadata" ...... 98
6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 98 6. SUPA ECAPolicyRule Information Model .......................... 99
6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 98 6.1. Overview ................................................. 99
6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 98 6.2. Constructing a SUPAECAPolicyRule ........................ 101
6.7. The Abstract Class "SUPABooleanClause" ................... 98 6.3. Working With SUPAECAPolicyRules ......................... 101
6.7.1. SUPABooleanClause Attributes ........................ 99 6.4. The Abstract Class "SUPAECAPolicyRule" .................. 103
6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 99 6.4.1. SUPAECAPolicyRule Attributes ....................... 105
6.7.2. SUPABooleanClause Relationships ..................... 99 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ..... 105
6.8. The Concrete Class "SUPABooleanClauseAtomic" ............ 100 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ....... 105
6.8.1. SUPABooleanClauseAtomic Attributes ................. 100 6.4.2. SUPAECAPolicyRule Relationships .................... 105
6.8.2. SUPABooleanClauseAtomic Relationships .............. 100 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............ 105
6.9. The Concrete Class "SUPABooleanClauseComposite" ......... 100 6.5.1. SUPAECAPolicyRuleAtomic Attributes ................. 106
6.9.1. SUPABooleanClauseComposite Attributes .............. 100 6.5.1.1. The Attribute "supaECAPolActionEvalStrategy" .. 106
6.9.1.1. The Attribute "supaBoolClauseBindValue" ....... 101 6.5.2. SUPAECAPolicyRuleAtomic Relationships .............. 107
6.9.1.2. The Attribute "supaBoolClauseIsCNF" ........... 101 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" ......... 107
6.9.2. SUPABooleanClauseComposite Relationships ........... 101 6.6.1. SUPAECAPolicyRuleComposite Attributes .............. 108
6.9.2.1. The Aggregation "SUPAHasBooleanClause" ........ 101 6.6.1.1. The Attribute "supaECAEvalRuleStrategy" ....... 108
6.9.3. The Association Class "SUPAHasBooleanClauseDetail" . 101 6.6.2. SUPAECAPolicyRuleComposite Relationships ........... 110
6.9.3.1. SUPAHasBooleanClauseDetail Attributes ......... 101 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ........ 110
6.10. The Abstract Class "SUPAECAComponent" .................. 102 6.6.2.2. The Association Class
6.10.1. SUPAECAComponent Attributes ....................... 102 "SUPAHasECAPolicyRuleDetail" .................. 109
6.10.1.1. The Attribute supaECACompIsTerm .............. 102 6.6.2.2.1. The Attribute "supaECAPolicyIsDefault" ... 109
6.10.2. SUPAECAComponent Relationships .................... 102 6.7. The Abstract Class "SUPABooleanClause" .................. 109
6.11. The Concrete Class "SUPAPolicyEvent" ................... 103 6.7.1. SUPABooleanClause Attributes ....................... 110
6.11.1. SUPAPolicyEvent Attributes ........................ 103 6.7.1.1. The Attribute "supaBoolClauseBindValue" ....... 110
6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 103 6.7.1.2. The Attribute "supaBoolClauseIsCNF" ........... 110
6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 103 6.7.1.3. The Attribute "supaBoolClauseIsNegated" ....... 111
6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 103 6.7.2. SUPABooleanClause Relationships .................... 111
6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 103 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............ 111
6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 104 6.8.1. SUPABooleanClauseAtomic Attributes ................. 111
6.11.2. SUPAPolicyEvent Relationships ..................... 104 6.8.2. SUPABooleanClauseAtomic Relationships .............. 111
6.12. The Concrete Class "SUPAPolicyCondition" ............... 104 6.9. The Concrete Class "SUPABooleanClauseComposite" ......... 111
6.12.1. SUPAPolicyCondition Attributes .................... 105 6.9.1. SUPABooleanClauseComposite Attributes .............. 112
6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 105 6.9.2. SUPABooleanClauseComposite Relationships ........... 112
6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 105 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ........ 112
6.12.2. SUPAPolicyEvent Relationships ..................... 105 6.9.2.2. The Association Class
6.13. The Concrete Class "SUPAPolicyAction" .................. 106 "SUPAHasBooleanClauseDetail" .................. 112
6.13.1. SUPAPolicyAction Attributes ....................... 106 6.9.2.2.1. The Attribute "supaIsHornClause" ............ 112
6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 106 6.10. The Abstract Class "SUPAECAComponent" .................. 113
6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 107 6.10.1. SUPAECAComponent Attributes ....................... 113
6.13.2. SUPAPolicyAction Relationships .................... 107 6.10.1.1. The Attribute "supaECACompIsTerm" ............ 113
6.10.2. SUPAECAComponent Relationships .................... 113
7. Examples ..................................................... 107 Table of Contents (continued)
8. Security Considerations ..................................... 107
9. IANA Considerations .......................................... 107 6.11. The Concrete Class "SUPAPolicyEvent" ................... 114
10. Contributors ................................................ 108 6.11.1. SUPAPolicyEvent Attributes ........................ 114
11. Acknowledgments ............................................. 108 6.11.1.1. The Attribute "supaPolicyEventData[1..n]" .... 114
12. References .................................................. 108 6.11.1.2. The Attribute "supaPolicyEventEncoding[1..n]" 115
12.1. Normative References ................................... 108 6.11.1.3. The Attribute "supaPolicyEventIsPreProcessed" 115
12.2. Informative References ................................ 108 6.11.1.4. The Attribute "supaPolicyEventIsSynthetic" ... 115
Authors' Addresses ............................................... 109 6.11.1.5. The Attribute "supaPolicyEventTopic[0..n]" ... 116
Appendix A. Brief Analyses of Previous Policy Work .............. 110 6.11.2. SUPAPolicyEvent Relationships ..................... 116
6.12. The Concrete Class "SUPAPolicyCondition" ............... 116
6.12.1. SUPAPolicyCondition Attributes .................... 116
6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 116
6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 117
6.12.2. SUPAPolicyCondition Relationships ................. 117
6.13. The Concrete Class "SUPAPolicyAction" .................. 117
6.13.1. Restrictions about SUPAPolicyActions Calling
SUPAPolicies ...................................... 118
6.13.2. SUPAPolicyAction Attributes ....................... 119
6.13.2.1. The Attribute "supaPolicyActionData[1..n]" ... 119
6.13.2.2. The Attribute "supaPolicyActionEncoding" ..... 119
6.13.3. SUPAPolicyAction Relationships .................... 120
7. Examples ..................................................... 121
7.1. Example 1: Blocking SNMP Traffic ....................... 121
7.1.1. Introduction ....................................... 121
7.1.2. Solution Approach .................................. 121
7.1.3. Solution for Case 1 (SUPAPolicies Control
Behavior) ....................................... 122
7.1.3.1. Strategy ................................... 123
7.1.3.2. Implementation ............................. 124
7.1.4. Solution for Case 2 (SUPAPolicies Do Not
Control Behavior) .................................. 127
7.1.4.1. Approach ...................................... 127
7.1.4.2. Implementation ............................. 128
8. Security Considerations ..................................... 130
9. IANA Considerations .......................................... 130
10. Contributors ................................................ 130
11. Acknowledgments ............................................. 130
12. References .................................................. 130
12.1. Normative References ................................... 130
12.2. Informative References ................................ 131
Authors' Addresses ............................................... 133
Appendix A. Brief Analyses of Previous Policy Work .............. 134
1. Overview 1. Overview
This document defines an information model for representing This document defines an information model for representing
policies using a common extensible framework that is independent policies using a common extensible framework that is independent
of language, protocol, repository, and the level of abstraction of of language, protocol, repository, and the level of abstraction of
the content and meaning of a policy. This enables a common set of the content and meaning of a policy. This enables a common set of
concepts defined in this information model to be mapped into concepts defined in this information model to be mapped into
different representations of policy (e.g., procedural, imperative, different representations of policy (e.g., procedural, imperative,
and declarative). It also enables different data models that use and declarative). It also enables different data models that use
different languages, protocols, and repositories to optimize different languages, protocols, and repositories to optimize
skipping to change at page 9, line 39 skipping to change at page 9, line 39
event-condition-action (ECA) paradigm; this is called the event-condition-action (ECA) paradigm; this is called the
SUPA ECA Policy Rule Information Model (EPRIM), and extends SUPA ECA Policy Rule Information Model (EPRIM), and extends
concepts from the GPIM. concepts from the GPIM.
The combination of the GPIM and the EPRIM provides an extensible The combination of the GPIM and the EPRIM provides an extensible
framework for defining policy that uses an event-condition-action framework for defining policy that uses an event-condition-action
representation that is independent of data repository, data representation that is independent of data repository, data
definition language, query language, implementation language, and definition language, query language, implementation language, and
protocol. protocol.
The Appendices describe how the structure of the GPIM defines a The Appendix provides a brief analysis of previous work in the
set of generic concepts that enables other types of policies, such field of policy modeling.
as declarative (or "intent-based") policies, to be added later.
1.1. Introduction 1.1. Introduction
Simplified Use of Policy Abstractions (SUPA) defines a technology- Simplified Use of Policy Abstractions (SUPA) defines a technology-
independent neutral information model for creating high-level, independent neutral information model for creating high-level,
possibly network-wide policies as input and producing element possibly network-wide policies as input and producing element
configurations (either whole or snippets) as output. SUPA addresses configurations (either whole or snippets) as output. SUPA addresses
the needs of operators, end-users, and application developers to the needs of operators, end-users, and application developers to
represent multiple types of ECA policy rules, such as for traffic represent multiple types of ECA policy rules, such as for traffic
selection and configuration or security. These ECA policy rules may selection and configuration or security. These ECA policy rules may
skipping to change at page 11, line 28 skipping to change at page 11, line 28
module MUST extend the GPIM to define a new type of policy rule by module MUST extend the GPIM to define a new type of policy rule by
adding to the GPIM. Each additoinal module MUST NOT alter any of adding to the GPIM. Each additoinal module MUST NOT alter any of
the model elements of the GPIM. The use of extensions preserves the the model elements of the GPIM. The use of extensions preserves the
interoperability of this approach; if the base GPIM was modified, interoperability of this approach; if the base GPIM was modified,
then this would adversely compromise interoperability. then this would adversely compromise interoperability.
The SUPA ECA Policy Rule Information Model (EPRIM) extends the The SUPA ECA Policy Rule Information Model (EPRIM) extends the
GPIM to represent policy rules that use the Event-Condition-Action GPIM to represent policy rules that use the Event-Condition-Action
(ECA) paradigm. (ECA) paradigm.
1.2. Changes Since Version -01 1.2. Changes Since Version -02
There are several changes in this version of this document There are several changes in this version of this document
compared to the previous versions of this document. They are: compared to the previous versions of this document. They are:
1) Clarified figure 7 and figure 17 1) Fixed ASCII art in several figures
2) Aligned enumerations in IM with those in DM and standardized 2) Added enumerations to supaPolOpType to sync with I2NSF
values in the IM version and their explanations 3) Fixed supaVendorDecoratedCompEncoding
3) Removed supaPolExecStatus and supaPolClauseExecStatus 4) Corrected attribute definitions in supaPolicyCollection
4) Added supaPolClauseDeployStatus attribute 5) Corrected attribute definition of supaPolMetadataIDEncoding
5) Rewrote SUPAPolicyComponentStructure definition 6) Added Figures 2 and 3; renumbered subsequent Figures
6) Rewrote SUPAPolicyClause definition 7) Enhanced supaPolicyEventEncoding definition
7) Synchronized information and data models. 8) Added supaECAPolActionEcalStrategy to SUPAPolicyRuleComposite
8) Deleted the attribute "supaEncodedClauseLang[0..n]" 9) Added section 6.13.1.
9) Fixed typos 10) Added new section about design patterns (4.2.1)
11) Added new section describing how association classes are
used (4.2.2)
12) ECA stuff
13) revised decorator pattern
14) Fixed typos
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. In this document are to be interpreted as described in [RFC2119]. In
this document, these words will appear with that interpretation this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to only when in ALL CAPS. Lower case uses of these words are not to
be interpreted as carrying [RFC2119] significance. be interpreted as carrying [RFC2119] significance.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
CLI Command Line Interface CLI Command Line Interface
CRUD Create, Read, Update, Delete CRUD Create, Read, Update, Delete
CNF Conjunctive Normal Form CNF Conjunctive Normal Form
DNF Disjunctive Normal Form DNF Disjunctive Normal Form
ECA Event-Condition-Action ECA Event-Condition-Action
EPRIM (SUPA) ECA Policy Rule Information Model EPRIM (SUPA) ECA Policy Rule Information Model
GPIM (SUPA) Generic Policy Information Model GPIM (SUPA) Generic Policy Information Model
OAM&P Operations, Administration, Management, and Provisioning OAM&P Operations, Administration, Management, and Provisioning
OID Object IDentifier OID Object IDentifier
SAT Satisfiability, short for Boolean Satisfiability Problem
SUPA Simplified Use of Policy Abstractions SUPA Simplified Use of Policy Abstractions
TMF TeleManagent Forum (TM Forum) TMF TeleManagent Forum (TM Forum)
UML Unified Modeling Language UML Unified Modeling Language
URI Uniform Resource Identifier URI Uniform Resource Identifier
YANG A data definition language for use with NETCONF YANG A data definition language for use with NETCONF
ZOOM Zero-touch Orchestration, Operations, and Management ZOOM Zero-touch Orchestration, Operations, and Management
(a TMF project that also works on information models) (a TMF project that also works on information models)
3.2. Definitions 3.2. Definitions
skipping to change at page 14, line 5 skipping to change at page 14, line 5
1. It uses metadata to define how its content is interpreted 1. It uses metadata to define how its content is interpreted
2. It separates the content of the policy from the 2. It separates the content of the policy from the
representation of the policy representation of the policy
3. It provides a convenient control point for OAM&P operations 3. It provides a convenient control point for OAM&P operations
The combination of these three functions enables a PolicyContainer The combination of these three functions enables a PolicyContainer
to define the behavior of how its constituent components will be to define the behavior of how its constituent components will be
accessed, queried, stored, retrieved, and how they operate. accessed, queried, stored, retrieved, and how they operate.
This document does NOT define a specific data type to implementation This document does NOT define a specific data type to implement
a PolicyContainer, as many different types of data types can be a PolicyContainer, as many different types of data types can be
used. However, the data type chosen SHOULD NOT allow duplicate used. However, the data type chosen SHOULD NOT allow duplicate
members in the PolicyContainer. In addition, order is irrelevant, members in the PolicyContainer. In addition, order is irrelevant,
since priority will override any initial order of the members of since priority will override any initial order of the members of
this PolicyContainer. this PolicyContainer.
3.2.2. Policy Terminology 3.2.2. Policy Terminology
The following terms define different policy concepts used in the The following terms define different policy concepts used in the
SUPA Generic Policy Information Model (GPIM). Note that the SUPA Generic Policy Information Model (GPIM). Note that the
skipping to change at page 14, line 30 skipping to change at page 14, line 30
3.2.2.1. SUPAPolicyObject 3.2.2.1. SUPAPolicyObject
A SUPAPolicyObject is the root of the GPIM class hierarchy. It is A SUPAPolicyObject is the root of the GPIM class hierarchy. It is
an abstract class that all classes inherit from, except the an abstract class that all classes inherit from, except the
SUPAPolicyMetadata class and its subclasses. SUPAPolicyMetadata class and its subclasses.
3.2.2.2. SUPAPolicy 3.2.2.2. SUPAPolicy
A SUPAPolicy is, in this version of this document, an ECA policy A SUPAPolicy is, in this version of this document, an ECA policy
rule that is a type of PolicyContainer. The PolicyContainer MUST rule that is a type of PolicyContainer. The PolicyContainer MUST
contain an ECA policy rule, SHOULD contain one or more contain a SUPAECAPolicyRule, SHOULD contain one or more
SUPAPolicyMetadata objects, and MAY contain other elements that SUPAPolicyMetadata objects, and MAY contain other elements that
define the semantics of the policy rule. Policies are generically define the semantics of the policy rule. Policies are generically
defined as a means to monitor and control the changing and/or defined as a means to monitor and control the changing and/or
maintaining of the state of one or more managed objects [1]. In maintaining of the state of one or more managed objects [1]. In
this context, "manage" means that one or more of the following six this context, "manage" means that one or more of the following six
fundamental operations are supported: create, read, write, delete, fundamental operations are supported: create, read, write, delete,
start, and stop) [16]. start, and stop) [16].
3.2.2.3. SUPAPolicyClause 3.2.2.3. SUPAPolicyClause
skipping to change at page 21, line 7 skipping to change at page 21, line 7
A C A C
+---------+ +---------+ +---------+ +---------+
| Class A | | Class B | | Class A | | Class B |
+---------+ +---------+ +---------+ +---------+
An Abstract Class A Concrete Class An Abstract Class A Concrete Class
4. Policy Abstraction Architecture 4. Policy Abstraction Architecture
This section describes the motivation for the policy abstractions This section describes the policy abstractions that are used in
that are used in SUPA. The following abstractions are provided: SUPA. The following abstractions are provided:
o The GPIM defines a technology-neutral information model that o The GPIM defines a technology-neutral information model that
can express the concept of Policy. can express the concept of Policy.
o All classes, except for SUPAPolicyMetadata, inherit from o All classes, except for SUPAPolicyMetadata, inherit from
SUPAPolicyObject, or one of its subclasses. SUPAPolicyObject, or one of its subclasses.
o SUPAPolicyObject and SUPAPolicyMetadata are designed to o SUPAPolicyObject and SUPAPolicyMetadata are designed to
inherit from classes in another model; the GPIM does not inherit from classes in another model; the GPIM does not
define an "all-encompassing" model. define an "all-encompassing" model.
o This version of this document restricts the expression of o This version of this document restricts the expression of
Policy to a set of event-condition-action clauses. Policy to a set of event-condition-action clauses.
o Each clause is defined as a Boolean expression, and MAY o Each clause is defined as a Boolean expression, and MAY
also be defined as a reusable object. also be defined as a reusable object.
o Clauses may be combined to form more complex Boolean o Clauses may be combined to form more complex Boolean
expressions. expressions.
o The purpose of the GPIM is to enable different policies that o The purpose of the GPIM is to enable different policies that
have fundamentally different representations to share common have fundamentally different representations to share common
model elements. Policy statements, which are implemented as model elements. Policy statements, which are implemented as
instances of the SUPAPolicyClause class, separates the content instances of the SUPAPolicyClause class, separate the content
of a Policy from its representation. This is supported by: of a Policy from its representation. This is supported by:
o All policy rules (of which SUPAECAPolicyRule is the o All policy rules (of which SUPAECAPolicyRule is the
first example of a concrete class) are derived from first example of a concrete class) are derived from
the SUPAPolicyStructure class. the SUPAPolicyStructure class.
o All objects that are components of policy rules are o All objects that are components of policy rules are
derived from the SUPAPolicyComponentStructure class. derived from the SUPAPolicyComponentStructure class.
o A SUPAPolicy MUST contain at least one SUPAPolicyClause. o A SUPAPolicy MUST contain at least one SUPAPolicyClause.
o A SUPAPolicy MAY specify one or more SUPAPolicyTarget, o A SUPAPolicy MAY specify one or more SUPAPolicyTarget,
SUPAPolicySource, and SUPAPolicyMetadata objects to SUPAPolicySource, and SUPAPolicyMetadata objects to
augment the semantics of the SUPAPolicy augment the semantics of the SUPAPolicy
o A SUPAPolicyClause has two subclasses: o A SUPAPolicyClause has two subclasses:
o A SUPABooleanClause, which is used to build o A SUPABooleanClause, which is used to build
SUPAECAPolicyRules from reusable objects. SUPAECAPolicyRules from reusable objects.
o A SUPAEncodedClause, which is used for using o A SUPAEncodedClause, which is used for using attributes
attributes instead of objects to construct a instead of objects to construct a SUPAECAPolicyRule.
SUPAECAPolicyRule.
o A SUPAECAPolicyRule defines the set of events and conditions o A SUPAECAPolicyRule defines the set of events and conditions
that are responsible for executing its actions; it MUST have that are responsible for executing its actions; it MUST have
at least one event clause, at least one condition clause, and at least one event clause, at least one condition clause, and
at least one action clause. at least one action clause.
o The action(s) of a SUPAECAPolicyRule are ONLY executed o The action(s) of a SUPAECAPolicyRule are ONLY executed
if both the event and condition clauses evaluate to TRUE if both the event and condition clauses evaluate to TRUE
o A SUPAPolicyAction MAY invoke another SUPAECAPolicyRule o A SUPAPolicyAction MAY invoke another SUPAPolicyAction in
(see section 6.13). another SUPAECAPolicyRule (see section 6.13).
o SUPAMetadata MAY be defined for any SUPAPolicyObject class. o SUPAMetadata MAY be defined for any SUPAPolicyObject class.
o SUPAMetadata MAY be prescriptive and/or descriptive in nature. o SUPAMetadata MAY be prescriptive and/or descriptive in nature.
This model, and its abstractions, define an interoperable
representation of policies that can be communicated between
different actors. Generation and execution of these policies
is beyond the scope of this document.
4.1. Motivation 4.1. Motivation
The power of policy management is its applicability to many The power of policy management is its applicability to many
different types of systems. There are many different actors that different types of systems. There are many different actors that
can use a policy management system, including end-users, operators, can use a policy management system, including end-users, operators,
application developers, and administrators. Each of these application developers, and administrators. Each of these
constituencies have different concepts and skills, and use constituencies have different concepts and skills, and use
different terminology. For example, an operator may want to express different terminology. For example, an operator may want to express
an operational rule that states that only Platinum and Gold users an operational rule that states that only Platinum and Gold users
can use streaming multimedia applications. As a second example, a can use streaming multimedia applications. As a second example, a
skipping to change at page 23, line 5 skipping to change at page 22, line 55
They may have no idea of the concepts used in each policy. Yet, They may have no idea of the concepts used in each policy. Yet,
their policies need to interact in order for the business to their policies need to interact in order for the business to
provide the desired service. This again underscores the need for provide the desired service. This again underscores the need for
a common policy framework. a common policy framework.
Certain types of policy rules (e.g., ECA) may express actions, or Certain types of policy rules (e.g., ECA) may express actions, or
other types of operations, that contradict each other. SUPA other types of operations, that contradict each other. SUPA
provides a rich object model that can be used to support language provides a rich object model that can be used to support language
definitions that can find and resolve such problems. definitions that can find and resolve such problems.
Models built using this IM are intended primarily for communicating
policy, not for executing policy.
4.2. SUPA Approach 4.2. SUPA Approach
The purpose of the SUPA Generic Policy Information Model (GPIM) is The purpose of the SUPA Generic Policy Information Model (GPIM) is
to define a common framework for expressing policies at different to define a common framework for expressing policies at different
levels of abstraction. SUPA uses the GPIM as a common vocabulary levels of abstraction. SUPA uses the GPIM as a common vocabulary
for representing policy concepts that are independent of language, for representing policy concepts that are independent of language,
protocol, repository, and level of abstraction. This enables protocol, repository, and level of abstraction. This enables
different actors to author and use policies at different levels of different actors to author and use policies at different levels of
abstraction. This forms a policy continuum [1] [2], where more abstraction. This forms a policy continuum [1] [2], where more
abstract policies can be translated into more concrete policies, abstract policies can be translated into more concrete policies,
and vice-versa. and vice-versa.
Most systems define the notion of a policy as a single entity. Most systems define the notion of a policy as a single entity.
This assumes that all users of policy have the same terminology, This assumes that all users of policy have the same terminology,
and use policy at the same level of abstraction. This is rarely, and use policy at the same level of abstraction. This is rarely,
if ever, true in modern systems. The policy continuum defines a if ever, true in modern systems. The policy continuum defines a
set of views (much like RM-ODP's viewpoints [9]) that are each set of views (much like RM-ODP's viewpoints [9]) that are each
optimized for a user playing a specific role. SUPA defines the optimized for an actor playing a specific role. SUPA defines the
GPIM as a standard vocabulary and set of concepts that enable GPIM as a standard vocabulary and set of concepts that enable
different actors to use different formulations of policy. This different actors to use different formulations of policy. This
corresponds to the different levels in the policy continuum, and corresponds to the different levels in the policy continuum, and
as such, can make use of previous experience in this area. as such, can make use of previous experience in this area.
It may be necessary to translate a Policy from a general to a more It may be necessary to translate a Policy from a general to a more
specific form (while keeping the abstraction level the same). For specific form (while keeping the abstraction level the same). For
example, the declarative policy "Every network attached to a VM example, the declarative policy "Every network attached to a VM
must be a private network owned by someone in the same group as must be a private network owned by someone in the same group as
the owner of the VM" may be translated to more formal form (e.g., the owner of the VM" may be translated to a more formal form (e.g.,
Datalog (as in OpenStack Congress). It may also be necessary to into Datalog, as in OpenStack Congress). It may also be necessary
translate a Policy to a different level of abstraction. For to translate a Policy to a different level of abstraction. For
example, the previous Policy may need to be translated to a form example, the previous Policy may need to be translated to a form
that network devices can process directly. This requires a common that network devices can process directly. This requires a common
framework for expressing policies that is independent of the level framework for expressing policies that is independent of the level
of abstraction that a Policy uses. of abstraction that a Policy uses.
4.2.1. Design Patterns
A design pattern defines a reusable solution to a commonly occuring
software design problem. It is not a finished solution, because of
its generic nature. Rather, it is a "template" that outlines how to
solve a problem that occurs in many different situations.
In order to provide internal and external consistency, the SUPA
Information Model uses several design patterns in key places withinhe
the model. The following sub-sections describe three of the design
patterns that this model uses.
4.2.1.1. Composite Pattern
One common issue is that some classes may need to be able to contain
other classes. A common analogy is a folder system - folders can
contain folders and files, but (typically) files do not contain
folders. This is addressed by the Composite Pattern.
The Composite Pattern creates a minimum of two subclasses, one for
representing objects that can stand alone (e.g., files), and one for
representing objects that serve as collections (e.g., folders). An
example of this is SUPAECAPolicyRule. The composite subclass (e.g.,
SUPAECAPolicyRuleComposite) has an aggregating association back to
or from the parent class (e.g., SUPAECAPolcyRule). This allows one
to have composite entities which are made up of either other
composites, or any of the atomic subclasses (e.g.,
SUPAECAPolicyRuleAtomic).
While some models use recursive associations for this, experience
has shown that this causes inappropriate associations, such as
leading to an atomic subclass being able to contain more complex
instances of the parent class.
4.2.1.2. Decorator Pattern
Another common issue is the need to have a highly extensible set of
additional information that MAY need to be added for certain object
instances. Some of this can be done with metadata, but often, the
information to be added forms a part of the object instance behavior.
This is addressed by the decorator pattern [11]. A good example is
SUPAPolicyClause, whose definition and behavior can be extended
dynamically at runtime by wrapping its object instance with
other objects. This is explained below.
An aggregation is defined between SUPAPolicyClause and the
superclass of the set of classes that form the Decorator Pattern
(i.e., SUPAPolicyClauseComponentDecorator). This aggregation
enables zero or more concrete subclasses of the
SUPAPolicyClauseComponentDecorator class to "wrap" (i.e., be
attached to) the instance of the class being decorated (i.e.,
SUPAPolicyClause in this example). This has the effect of creating a
new object that appears to be a SUPAPolicyClause, but contains new
attributes and behavior that are added to the existing attributes
and behavior of the SUPAPolicyClause. Clients that are using the
decorated object (i.e., SUPAPolicyClause) are **not** aware of
these changes.
The SUPAPolicyClauseComponentDecorator class has a number of
specific subclases that each represent additional kinds of
information that can be attached to a SUPAPolicyClause object
instance. In this example, concrete subclasses of SUPAPolicyTerm
and SUPAECAComponent, along with SUPAPolicyCollection and other
subclasses, define optional information that can be attached to a
SUPAPolicyClause. More specifically, each concrete subclass of the
SUPAPolicyClause class can be decorated by each concrete subclass of
the SUPAPolicyClauseComponentDecorator class. This means that the
SUPAPolicyClauseComponentDecorator object has an instance variable
that holds a reference to a SUPAPolicyClause object. Since the
SUPAPolicyClauseComponentDecorator object has the same interface as
the SUPAPolicyClause object, the SUPAPolicyClauseComponentDecorator
class (and all of its subclasses) are transparent to clients of the
SUPAPolicyClause class (and its subclasses). Hence, all
SUPAPolicyClauseComponentDecorator object instances can add
attributes and/or methods to the concrete instance of the chosen
subclass of SUPAPolicyClause.
Figure 2 shows how this is done for methods.
- Figure 2a shows the initial object to be wrapped
- Figure 2b shows the SUPAPolicyEvent object wrapping the
SUPAEncodedClause object
- Figure 2c shows SUPAGenericDecoratedComponent object
wrapping the SUPAPolicyEvent object.
+-------------------+
| SUPAEncodedClause |
| eval() | ===>
+-------------------+
(a) Initial Object
+------------------------+
| SUPAPolicyEvent |
| eval() |
| +-------------------+ |
| | SUPAEncodedClause | | ===>
| | eval() | |
| +-------------------+ |
+------------------------+
(b) SUPAPolicyEvent "wraps" SUPAEncodedClause
+--------------------------------+
| SUPAGenericDecoratedComponent |
| eval() |
| +-----------------------+ |
| | SUPAPolicyEvent | |
| | eval() | |
| | +-------------------+ | |
| | | SUPAEncodedClause | | |
| | | eval() | | |
| | +-------------------+ | |
| +-----------------------+ |
+--------------------------------+
(c) SUPAGenericDecoratedComponent "wraps" SUPAPolicyEvent
Figure 2. Conceptual Depiction of eval() Decorated Method
When the eval() method is called in the outermost object
(SUPAGenericDecoratedComponent), it delegates to the eval() method
of SUPAPolicyEvent, which in turn delegates to the eval() method
of SUPAEncodedClause. This method executes and returns the
results to SUPAPolicyEvent, which executes and returns the results
to SUPAGenericDecoratedComponent, which executes and returns the
final result.
In addition, decorators may be applied to decorators. This is
accomplished by using a concrete subclass of the decorating classes
(SUPAPolicyComponentDecorator), which then decorates a concrete
subclass of the parent decorator (i.e.,
SUPAPolicyClauseComponentDecorator). This enables the basic
information to have either individual decorations or complex
decorator aggregates.
4.2.2. Association Classes
An association class enables attributes, operations, and other
features to be added to an association. Consider the following
example. An Employee can work for a Company, in which case the
Company pays the Employee a salary. Now, where do you define the
salary attribute? If you define the salary as part of the Company,
then every Employee gets the same salary. If you define salary as
an attribute of Employee, then that Employee gets the same salary
for all Companies that the Employee works for.
These problems result from the fact that different Employees can
work for the same Company, and an Employee may also work for
different Companies. Hence, the salary paid to the Employee is in
reality a function of the relationship between Employee and
Company, since the salary changes when the Employee works for a
different Company. This is shown in Figure 3.
C C
+----------+ 1..n 0..n +---------+
| | IsEmployedBy | |
| Employee +--------+-------+ Company |
| | ^ | |
+----------+ | +---------+
|
C |
+--------+-----------+
| IsEmployedByDetail |
| |
| salary : Float |
| |
+--------------------+
Figure 3. Using Association Classes
Figure 3 shows that a class, named IsEmployedByDetail, is used to
represent the semantics of the IsEmployedBy association.
Note that an association class can define its own (i.e., class-
level) attributes, methods, and relationships; all of these can be
used to define the intended semantics of the association class.
Note: class-level attributes, methods, and relationships are often
called **static** attributes, methods, and relationships.
Examples include:
o restrict when the relationship can be established and/or
terminated
o restrict which classes of one end of the relationship can be
associated with which classes from the other end of the
relationship
o define attributes that depend on both classes in the
relationship
In the above example, the use of a class enables the attributes of
the association class (i.e., IsEmployedByDetail) to be used to
define the salary attribute. This is because the salary attribute is
a function of both the particular Employee being paid the salary
and the Company that the Employee works for. In this example, we
have chosen to give the salary attribute a datatype of type Float.
Optionally, the association class can be subclassed to refine
additional behavior. In addition, the association class can have
its own set of relationships; these relationships could be used
make the attributes of the association class dependent on
other classes.
4.3. SUPA Generic Policy Information Model Overview 4.3. SUPA Generic Policy Information Model Overview
Figure 2 illustrates the approach for representing policy rules Figure 5 illustrates the approach for representing policy rules
in SUPA. The top two layers are defined in this document; the in SUPA. The top two layers are defined in this document; the
bottom layer (Data Models) are defined in separate documents. bottom layer (Data Models) are defined in separate documents.
Conceptually, the GPIM defines a set of objects that define the Conceptually, the GPIM defines a set of objects that define the
key elements of a Policy independent of how it is represented or key elements of a Policy independent of how it is represented or
its content. As will be shown, there is a significant difference its content. As will be shown, there is a significant difference
between SUPAECAPolicyRules (see Section 6) and other types of between SUPAECAPolicyRules (see Section 6) and other types of
policies (see Section 7). In principle, other types of SUPAPolicies policies (see Section 7). In principle, other types of SUPAPolicies
could be defined, but the current charter is restricted to using could be defined, but the current charter is restricted to using
only event-condition-action SUPAPolicies as exemplars. only event-condition-action SUPAPolicies as exemplars.
skipping to change at page 24, line 26 skipping to change at page 28, line 26
| Information Model (EPRIM) | | are Derived from the GPIM | | Information Model (EPRIM) | | are Derived from the GPIM |
+-----------+---------------+ +-------------+-------------+ +-----------+---------------+ +-------------+-------------+
/ \ / \ / \ / \
| | | |
| | | |
+-----------+-----------+ +-----------+------------+ +-----------+-----------+ +-----------+------------+
| ECAPolicyRule | | Other Types of | | ECAPolicyRule | | Other Types of |
| Data Model | | Data Models | | Data Model | | Data Models |
+-----------------------+ +------------------------+ +-----------------------+ +------------------------+
Figure 2. Overview of SUPA Policy Rule Abstractions Figure 5. Overview of SUPA Policy Rule Abstractions
This draft defines the GPIM and EPRIM. This draft further assumes This draft defines the GPIM and EPRIM. This draft further assumes
that the SUPA Information Model is made up of either the GPIM or the that the SUPA Information Model is made up of either the GPIM or the
combination of the GPIM and the EPRIM. Extensions to both the GPIM combination of the GPIM and the EPRIM. Extensions to both the GPIM
and the EPRIM can be made as long as these extensions do not and the EPRIM can be made as long as these extensions do not
conflict with the content and structure defined in the GPIM and conflict with the content and structure defined in the GPIM and
EPRIM. If the GPIM and EPRIM are part of another information model, EPRIM. If the GPIM and EPRIM are part of another information model,
then they should collectively still define a single information then they should collectively still define a single information
model. The GPIM defines the following concepts: model. The GPIM defines the following concepts:
skipping to change at page 25, line 34 skipping to change at page 29, line 34
I +------------------+ I I I +------------------+ I I
I I I I I I
I +-------------+ I I +-------------+ I
I I +-----+-------+ I I +-----+-------+
I C I I I I C I I I
I +-------+----------+ A I I I +-------+----------+ A I I
I | SUPAPolicyTarget | +--------+---------+ I I | SUPAPolicyTarget | +--------+---------+ I
I +------------------+ | SUPAPolicyClause | I I +------------------+ | SUPAPolicyClause | I
A I +------------------+ I A I +------------------+ I
+-----+------------+ I +-----+------------+ I
| SUPAECAPolicyRule| A I | SUPAECAPolicyRule| A I
+------------------+ +--------------------+---------+ +------------------+ +--------------------------+---------+
| SUPAPolicyComponentDecorator | | SUPAPolicyClauseComponentDecorator |
+------------------------------+ +------------------------------------+
Figure 3. Functional View of the Top-Level GPIM Figure 6. Functional View of the Top-Level GPIM
Note that all classes except the SUPAPolicySource and the Note that all classes except the SUPAPolicySource and the
SUPAPolicyTarget classes are defined as abstract. This provides SUPAPolicyTarget classes are defined as abstract. This provides
more freedom for the data modeler in implementing the data model. more freedom for the data modeler in implementing the data model.
For example, if the data model uses an object-oriented language, For example, if the data model uses an object-oriented language,
such as Java, then the above structure enables all of the abstract such as Java, then the above structure enables all of the abstract
classes to be collapsed into a single concrete class. If this is classes to be collapsed into a single concrete class. If this is
done, attributes as well as relationships are inherited. done, attributes as well as relationships are inherited.
4.3.1. SUPAPolicyObject 4.3.1. SUPAPolicyObject
skipping to change at page 26, line 50 skipping to change at page 30, line 50
SUPAPolicyStructure subclasses define the structure of a policy, SUPAPolicyStructure subclasses define the structure of a policy,
while SUPAPolicyComponentStructure subclasses define the content while SUPAPolicyComponentStructure subclasses define the content
that is contained in the structure of a policy. For example, a that is contained in the structure of a policy. For example, a
SUPAECAPolicyRule is an imperative policy rule, and defines its SUPAECAPolicyRule is an imperative policy rule, and defines its
structure; its event, condition, and action clauses are populated structure; its event, condition, and action clauses are populated
by SUPAPolicyComponentStructure subclasses. The strength of this by SUPAPolicyComponentStructure subclasses. The strength of this
design is that different types of policies (e.g., imperative and design is that different types of policies (e.g., imperative and
declarative policies) can be represented using a common set of declarative policies) can be represented using a common set of
policy components. policy components.
Please see Appendix for a comparison to previous work. Please see the Appendix for a comparison to previous work.
4.3.4. SUPAPolicyClause 4.3.4. SUPAPolicyClause
All policies derived from the GPIM are made up of one or more All policies derived from the GPIM are made up of one or more
SUPAPolicyClauses, which define the content of the Policy. SUPAPolicyClauses, which define the content of the Policy.
This enables a Policy of one type (e.g., ECA) to invoke Policies This enables a Policy of one type (e.g., ECA) to invoke Policies
of the same or different types. SUPAPolicyClause is an abstract of the same or different types. SUPAPolicyClause is an abstract
class, and serves as a convenient aggregation point for assembling class, and serves as a convenient aggregation point for assembling
other objects that make up a SUPAPolicyClause. other objects that make up a SUPAPolicyClause.
skipping to change at page 27, line 30 skipping to change at page 31, line 30
The structure of the GPIM is meant to provide an extensible The structure of the GPIM is meant to provide an extensible
framework for defining different types of policies. This is framework for defining different types of policies. This is
demonstrated by the EPRIM (see section 6) and the LSIM (see the demonstrated by the EPRIM (see section 6) and the LSIM (see the
Appendices) that each define new subclasses of SUPAPolicyClause Appendices) that each define new subclasses of SUPAPolicyClause
(i.e., SUPABooleanClause and SUPALogicClause, respectively) (i.e., SUPABooleanClause and SUPALogicClause, respectively)
without defining new classes that have no GPIM superclass. without defining new classes that have no GPIM superclass.
A SUPAPolicyClause is defined as an object. Therefore, clauses and A SUPAPolicyClause is defined as an object. Therefore, clauses and
sets of clauses are objects, which promotes reusability. sets of clauses are objects, which promotes reusability.
4.3.5. SUPAPolicyComponentDecorator 4.3.5. SUPAPolicyClauseComponentDecorator
One of the problems in building a policy model is the tendency to One of the problems in building a policy model is the tendency to
have a multitude of classes, and hence object instances, to have a multitude of classes, and hence object instances, to
represent different combinations of policy events, conditions, and represent different combinations of policy events, conditions, and
actions. This can lead to class and/or relationship explosion. actions. This can lead to class and/or relationship explosion.
Please see Appendix A for a comparison to previous work. Please see Appendix A for a comparison to previous work.
SUPAPolicyClauses are constructed using the Decorator Pattern SUPAPolicyClauses are constructed using the Decorator Pattern
[11]. This is a design pattern that enables behavior to be [11]. This is a design pattern that enables behavior to be
selectively added to an individual object, either statically or selectively added to an individual object, either statically or
skipping to change at page 28, line 5 skipping to change at page 32, line 5
parts or all of existing objects without affecting the existing parts or all of existing objects without affecting the existing
objects. objects.
This enables the resulting SUPAPolicyClause to be constructed This enables the resulting SUPAPolicyClause to be constructed
completely from objects in the SUPA information model. This completely from objects in the SUPA information model. This
facilitates the construction of policies at runtime by a machine. facilitates the construction of policies at runtime by a machine.
This is also true of [2] and [5]; however, this is NOT true of This is also true of [2] and [5]; however, this is NOT true of
most other models. Please see Appendix A for a comparison to most other models. Please see Appendix A for a comparison to
previous work. previous work.
SUPAPolicyComponentDecorator defines four types of objects that SUPAPolicyClauseComponentDecorator is the superclass for 4 classes
can be used to form a SUPAPolicyClause. Each object may be used in the GPIM, and one additional class in the EPRIM, that can be used
with all other objects, if desired. The first three are defined to form a SUPAPolicyClause. Each of these five classes may be used
in the GPIM, with the last defined in the EPRIM. The objects are: with all other classes, if desired. These classes are:
o SUPAPolicyTerm, which enables a clause to be defined in a o SUPAPolicyTerm, which enables a clause to be defined in a
canonical {variable, operator, value} form canonical {variable, operator, value} form
o SUPAGenericDecoratedComponent, which enabled a custom object o SUPAGenericDecoratedComponent, which enabled a custom object
to be defined and then used in a SUPAPolicyClause to be defined and then used in a SUPAPolicyClause
o SUPAPolicyCollection, which enables a collection of objects o SUPAPolicyCollection, which enables a collection of objects
to be gathered together and associated with all or a portion to be gathered together and associated with all or a portion
of a SUPAPolicyClause of a SUPAPolicyClause
o SUPAPolicyComponentDecorator, which enables additional
Decorators to wrap the SUPAPolicyClauseComponentDecorator
o SUPAECAComponent, which defines Events, Conditions, and o SUPAECAComponent, which defines Events, Conditions, and
Actions as reusable objects Actions as reusable objects
This approach facilitates the machine-driven construction of This approach facilitates the machine-driven construction of
policies. Note that this is completely optional; policies do not policies. Note that this is completely optional; policies do not
have to use these constructs. have to use these constructs.
4.3.6. SUPAPolicyTarget 4.3.6. SUPAPolicyTarget
A SUPAPolicyTarget is a set of managed entities that a SUPAPolicy A SUPAPolicyTarget is a set of managed entities that a SUPAPolicy
is applied to. A managed entity can only be designated a is applied to. A set includes individual and group membership.
SUPAPolicyTarget if it can process actions from a SUPAPolicy. Data models implementations are free to populate the set using any
appropriate mechanisms, such as reference by a property such as one
or more roles, explicit lists, predicate expressions, or others.
A managed object may not be in a state that enables management Note that the decision to define a managed entity as a
operations to be performed on it. Furthermore, the policy-based SUPAPolicyTarget belongs with the management system; this
model simply represents the fact that a given managed entity is
defined as a SUPAPolicyTarget. Furthermore, the policy-based
management system SHOULD ensure that the management entity management system SHOULD ensure that the management entity
performing the management operations has the proper permissions to performing the management operations has the proper permissions to
perform the management operations. The design of the perform the requested management operations. The design of the
SUPAPolicyTarget addresses both of these criteria. SUPAPolicyTarget addresses both of these criteria.
4.3.7. SUPAPolicySource 4.3.7. SUPAPolicySource
A SUPAPolicySource is a set of managed entities that authored, or A SUPAPolicySource is a set of managed entities that authored, or
are otherwise responsible for, this SUPAPolicy. Note that a are otherwise responsible for, this SUPAPolicy. Note that a
SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its
primary use is for auditability and the implementation of deontic primary use is for auditability and the implementation of deontic
and/or alethic logic. and/or alethic logic.
4.4. The Design of the GPIM 4.4. The Design of the GPIM
This section describes the overall design of the GPIM.
The GPIM defines a policy as a type of PolicyContainer. For this The GPIM defines a policy as a type of PolicyContainer. For this
version, only ECA Policy Rules will be described. However, it version, only ECA Policy Rules will be described. However, it
should be noted that the mechanism described is applicable to should be noted that the mechanism described is applicable to
other types of policies (e.g., declarative) as well. other types of policies (e.g., declarative) as well.
4.4.1. Structure of Policies 4.4.1. Structure of Policies
Recall that a PolicyContainer was defined as a special type of Recall that a PolicyContainer was defined as a special type of
container that provides at least the following three functions: container that provides at least the following three functions:
skipping to change at page 29, line 34 skipping to change at page 33, line 34
strictly speaking, "rules", the former is named PolicyStructure, strictly speaking, "rules", the former is named PolicyStructure,
while the latter is named PolicyComponentStructure. while the latter is named PolicyComponentStructure.
The third requirement is met by the concrete subclasses of The third requirement is met by the concrete subclasses of
PolicyStructure. Since they are PolicyContainers, they are made PolicyStructure. Since they are PolicyContainers, they are made
up of the SUPAECAPolicyRule, its commponents, and any metadata up of the SUPAECAPolicyRule, its commponents, and any metadata
that applies to the PolicyContainer, the SUPAECAPolicyRule, and.or that applies to the PolicyContainer, the SUPAECAPolicyRule, and.or
any components of the SUPAECAPolicyRule. This provides optional any components of the SUPAECAPolicyRule. This provides optional
low-level control over any part of the SUPAECAPolicyRule. low-level control over any part of the SUPAECAPolicyRule.
The above requirements result in the design shown in Figure 4. The above requirements result in the design shown in Figure 7.
A SUPAHasPolicyMetadata A A SUPAHasPolicyMetadata A
+------------------+/ \ \+--------------------+ +------------------+/ \ \+--------------------+
| SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata | | SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata |
+---------+--------+\ / /+--------------------+ +---------+--------+\ / /+--------------------+
/ \ 0..n 0..n / \ 0..n 0..n
I I
I I
+------+------------------------------------+ +------+------------------------------------+
I I I I
A I A I A I A I
+--------+------------+ +------------------+-----------+ +--------+------------+ +------------------+-----------+
| SUPAPolicyStructure | | SUPAPolicyComponentStructure | | SUPAPolicyStructure | | SUPAPolicyComponentStructure |
+--------+------------+ +-------------+----------------+ +--------+------------+ +-------------+----------------+
/ \ / \ / \ / \
I I I I
I I I I
(subclasses representing (subclasses representing (subclasses representing (subclasses representing
different types of policies) different policy components) different types of policies) different policy components)
Figure 4. Structure of a Policy Figure 7. Structure of a Policy
Note that aggregation in Figure 4 (named SUPAHasPolicyMetadata) Note that aggregation in Figure 7 (named SUPAHasPolicyMetadata)
is realized as an association class, in order to manage which set is realized as an association class, in order to manage which set
of Metadata can be aggregated by which SUPAPolicyObject. The of Metadata can be aggregated by which SUPAPolicyObject. The
combination of these three functions enables a PolicyContainer combination of these three functions enables a PolicyContainer
to define the behavior of how its constituent components will be to define the behavior of how its constituent components will be
accessed, queried, stored, retrieved, and how they operate. accessed, queried, stored, retrieved, and how they operate.
It is often necessary to construct groups of policies. The GPIM It is often necessary to construct groups of policies. The GPIM
follows [2] and [5], and uses the composite pattern [11] to follows [2] and [5], and uses the composite pattern [11] to
implement this functionality, as shown in Figure 5 below. There implement this functionality, as shown in Figure 8 below. There
are a number of advantages to using the composite pattern over a are a number of advantages to using the composite pattern over a
simple relationship, as detailed in [11]. simple relationship, as detailed in [11].
Figure 5 shows that SUPAPolicyStructure has a single subclass, Figure 8 shows that SUPAPolicyStructure has a single subclass,
called SUPAECAPolicyRule. Note, however, that other types of called SUPAECAPolicyRule. Note, however, that other types of
policies, such as declarative policies, can be defined as policies, such as declarative policies, can be defined as
subclasses of SUPAPolicyStructure in the future. subclasses of SUPAPolicyStructure in the future.
A A
+---------------------+ +---------------------+
| SUPAPolicyStructure | | SUPAPolicyStructure |
+--------+------------+ +--------+------------+
/ \ / \
I I
I I
+---------------+----------------+ +---------------+----------------+
I I I I
C I A I C I A I
+----------------+---------------+ +-----------+-----------+ +----------------+---------------+ +-----------+-----------+
| Future Subclasses to Represent | | SUPAECAPolicyRule | | Future Subclasses to Represent | | SUPAECAPolicyRule |
| Represent Different Policies | +-----------------------+ | Represent Different Policies | +-----------------------+
+--------------------------------+ +--------------------------------+
Figure 5. The Composite Pattern Applied to SUPAPolicyStructure Figure 8. The Composite Pattern Applied to SUPAPolicyStructure
4.4.2. Representing an ECA Policy Rule 4.4.2. Representing an ECA Policy Rule
An ECA policy rule is a 3-tuple, which is made up of an event An ECA policy rule is a 3-tuple, which is made up of an event
clause, a condition clause, and an action clause. Each of these clause, a condition clause, and an action clause. Each of these
three types of clauses may in turn be made up of a Boolean three types of clauses may in turn be made up of a Boolean
combination of clauses of that type. Each clause may be viewed as combination of clauses of that type. Each clause may be viewed as
a predicate, as it provides a TRUE or FALSE output. The canonical a predicate, as it provides a TRUE or FALSE output. The canonical
form of a clause is a 3-tuple of the form "variable operator value", form of a clause is a 3-tuple of the form "variable operator value",
and can be made into more complex Boolean expressions. For example, and can be made into more complex Boolean expressions. For example,
the SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two the SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two
clauses, "(A AND B)" and "(C OR D)", that are combined together clauses, "(A AND B)" and "(C OR D)", that are combined together
using the operators OR and NOT. using the operators OR and NOT.
A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract
subclass of SUPAPolicyStructure. subclass of SUPAPolicyStructure.
A A Note that the aggregation SUPAHasPolicyClause in Figure 9 is
+---------------------------+ +------------------+
| SUPAPolicyStructure | | SUPAPolicyClause |
+---------+---------+-------+ +--------+----+----+
/ \ / \ 0..1 1..n / \ / \
I A | I
I \ / | I
I | | I
I | SUPAHasPolicyClause | I
I +------------------------+ I
A I A I
+------+------------+ +----------+-------+
| SUPAECAPolicyRule | | SUPAPolicyClause |
+-------------------+ +------------------+
Figure 6. SUPAECAPolicyRule Aggregating SUPAPolicyClauses
Note that the aggregation SUPAHasPolicyClause in Figure 6 is
realized as an association class, in order to manage which set realized as an association class, in order to manage which set
of SUPAPolicyClauses can be aggregated by which set of of SUPAPolicyClauses can be aggregated by which set of
SUPAECAPolicyRules. This aggregation is defined at the SUPAECAPolicyRules. This aggregation is defined at the
SUPAPolicyStructure level, and not at the lower level of SUPAPolicyStructure level, and not at the lower level of
SUPAECAPolicyRule, so that non-ECA policies can also use this SUPAECAPolicyRule, so that non-ECA policies can also use this
aggregation. aggregation.
A A
+---------------------------+ +------------------+
| SUPAPolicyStructure | | SUPAPolicyClause |
+---------+---------+-------+ +----------+-------+
/ \ / \ 0..1 1..n / \
I A |
I \ / |
I | |
I | SUPAHasPolicyClause |
I +---------------+----------+
A I I
+--------+----------+ A I
| SUPAECAPolicyRule | +--------+------------------+
+-------------------+ | SUPAHasPolicyClauseDetail |
+---------------------------+
Figure 9. SUPAECAPolicyRule Aggregating SUPAPolicyClauses
Since a SUPAECAPolicyRule consists of three SUPAPolicyClauses, Since a SUPAECAPolicyRule consists of three SUPAPolicyClauses,
at least three separate instances of the SUPAHasPolicyClause at least three separate instances of the SUPAHasPolicyClause
aggregation are instantiated in order to make a complete aggregation are instantiated in order to make a complete
SUPAECAPolicyRule, as shown in Figure 7. SUPAECAPolicyRule, as shown in Figure 10.
A A A A
+-------------------+ +--------------------+ +-------------------+ +--------------------+
| SUPAECAPolicyRule | | SUPAPolicyClause | | SUPAECAPolicyRule | | SUPAPolicyClause |
+--+----+----+------+ +-------+----+----+--+ +--+----+----+------+ +-------+----+----+--+
/ \ / \ / \ 1..n 0..n / \ / \ / \ / \ / \ / \ 0..1 1..n / \ / \ / \
A A A | | | A A A | | |
\ / \ / \ / | | | \ / \ / \ / | | |
| | | | | | | | | | | |
| | | SUPAHasPolicyClause #1 | | | | | | SUPAHasPolicyClause #1 | | |
| | +------------------------------+ | | | | +------------------------------+ | |
| | | | | | | |
| | SUPAHasPolicyClause #2 | | | | SUPAHasPolicyClause #2 | |
| +----------------------------------------+ | | +----------------------------------------+ |
| | | |
| SUPAHasPolicyClause #3 | | SUPAHasPolicyClause #3 |
+--------------------------------------------------+ +--------------------------------------------------+
note: all 3 aggregations have a multiplicity of 1..n - 0..n note: all 3 aggregations have a multiplicity of 0..1 - 1..n
Figure 7. Instantiating a SUPAECAPolicyRule, part 1 Figure 10. Instantiating a SUPAECAPolicyRule, part 1
In figure 7, SUPAECAPolicyRule is shown as "owning" these three In figure 10, SUPAECAPolicyRule is shown as "owning" these three
aggregations, since it inherits them from its superclass aggregations, since it inherits them from its superclass
(SUPAPolicyStructure). The three aggregations represent the (SUPAPolicyStructure). The three aggregations represent the
event, condition, and action clauses of a SUPAECAPolicyRule. event, condition, and action clauses of a SUPAECAPolicyRule.
Note that each of these clauses MAY consist of one or more Note that each of these clauses MAY consist of one or more
SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist
of one or more predicates. In this way, complex event, condition, of one or more predicates. In this way, complex event, condition,
and action clauses, which are combinations of Boolean expressions and action clauses, which are combinations of Boolean expressions
that form a logical predicate) are supported, without having to that form a logical predicate) are supported, without having to
define additonal objects (as is done in previous work; please define additonal objects (as is done in previous work; please
see Appendix A for a comparison to previous work. see Appendix A for a comparison to previous work.
skipping to change at page 32, line 36 skipping to change at page 36, line 36
aggregation (which is inherited by SUPAECAPolicyRule), the aggregation (which is inherited by SUPAECAPolicyRule), the
cardinality is defined to be 1..n on the part side because other cardinality is defined to be 1..n on the part side because other
types of Policies have different needs. The 0..n cardinality types of Policies have different needs. The 0..n cardinality
means that a SUPAPolicyClause may be aggregated by zero or more means that a SUPAPolicyClause may be aggregated by zero or more
SUPAECAPolicyRules. The zero is provided so that SUPAPolicyClauses SUPAECAPolicyRules. The zero is provided so that SUPAPolicyClauses
can be stored in (for example) a repository before the can be stored in (for example) a repository before the
SUPAECAPolicyRule is created; the "or more" recognizes the fact SUPAECAPolicyRule is created; the "or more" recognizes the fact
that multiple SUPAECAPolicyRules could aggregate the same that multiple SUPAECAPolicyRules could aggregate the same
SUPAPolicyClause. SUPAPolicyClause.
In Figure 7, suppose that SUPAHasPolicyClause#1, #2, and #3 In Figure 10, suppose that SUPAHasPolicyClause#1, #2, and #3
represent the aggregations for the event, condition, and action represent the aggregations for the event, condition, and action
clauses, respectively. This means that each of these clauses, respectively. This means that each of these
SUPAHasPolicyClause aggregations must explicitly identify the SUPAHasPolicyClause aggregations must explicitly identify the
type of clause that it represents. type of clause that it represents.
In looking at Figure 7, there is no difference between any of the In looking at Figure 10, there is no difference between any of the
three aggregations, except for the type of clause that the three aggregations, except for the type of clause that the
aggregation represents (i.e., event, condition, or action clause). aggregation represents (i.e., event, condition, or action clause).
Therefore, three different aggregations, each with their own Therefore, three different aggregations, each with their own
association class, is not needed. Instead, the GPIM defines a association class, is not needed. Instead, the GPIM defines a
single aggregation (SUPAHasPolicyClause) that is realized using a single aggregation (SUPAHasPolicyClause) that is realized using a
(single) abstract association class (SUPAHasPolicyClauseDetail); (single) abstract association class (SUPAHasPolicyClauseDetail);
this association class is then subclassed into three concrete this association class is then subclassed into three concrete
subclasses, one each to represent the semantics for an event, subclasses, one each to represent the semantics for an event,
condition, and action clause. condition, and action clause.
skipping to change at page 33, line 15 skipping to change at page 37, line 15
The policy management system may use any number of different The policy management system may use any number of different
software mechanisms, such as introspection or reflection, to software mechanisms, such as introspection or reflection, to
determine the nature of the aggregation (i.e., what object types determine the nature of the aggregation (i.e., what object types
are being aggregated) in order to select the appropriate subclass are being aggregated) in order to select the appropriate subclass
of SUPAHasPolicyClauseDetail. The three subclasses of of SUPAHasPolicyClauseDetail. The three subclasses of
SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail, SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail,
SUPAHasPolicyConditionDetail, and SUPAHasPolicyActionDetail, SUPAHasPolicyConditionDetail, and SUPAHasPolicyActionDetail,
respectively. While Event, Condition, and Action objects are respectively. While Event, Condition, and Action objects are
typically used in ECA policy rules, the design in this document typically used in ECA policy rules, the design in this document
enables them to be used as policy components of other types of enables them to be used as policy components of other types of
policies as well. This is shown in Figure 8. policies as well. This is shown in Figure 11.
A A A A
+-------------------+ +------------------+ +-------------------+ +------------------+
| SUPAECAPolicyRule | | SUPAPolicyClause | | SUPAECAPolicyRule | | SUPAPolicyClause |
+---------+---------+ +----------+-------+ +---------+---------+ +----------+-------+
/ \ 1..n 0..n / \ / \ 1..n 0..n / \
A | A |
\ / | \ / |
| | | |
| SUPAHasPolicyClause | | SUPAHasPolicyClause |
skipping to change at page 33, line 43 skipping to change at page 37, line 43
/ \ / \
I I
I I
+----------------+-----------------------+ +----------------+-----------------------+
I I I I I I
C I C I C I C I C I C I
+--------+-----+ +-------+----------+ +---------+-----+ +--------+-----+ +-------+----------+ +---------+-----+
|Event subclass| |Condition subclass| |Action subclass| |Event subclass| |Condition subclass| |Action subclass|
+--------------+ +------------------+ +---------------+ +--------------+ +------------------+ +---------------+
Figure 8. Instantiating a SUPAECAPolicyRule, part 2 Figure 11. Instantiating a SUPAECAPolicyRule, part 2
4.4.3. Creating SUPA Policy Clauses 4.4.3. Creating SUPA Policy Clauses
There are two different types of Policy Components. They are a There are two different types of Policy Components. They are a
SUPAPolicyClause and a SUPAPolicyComponentDecorator. The former SUPAPolicyClause and a SUPAPolicyClauseComponentDecorator. The
is used to construct SUPAECAPolicyRules, while the latter is used former is used to construct SUPAECAPolicyRules, while the latter
to add behavior to a SUPAPolicyClause. This enables the structure is used to add behavior to a SUPAPolicyClause. This enables the
and capabilities of the SUPAPolicyClause to be adjusted structure and capabilities of the SUPAPolicyClause to be adjusted
dynamically at runtime. dynamically at runtime. This is shown in Figure 12.
However, since each SUPAECAPolicyRule can be made up of a variable
number of SUPAPolicyComponents, the decorator pattern is used to
"wrap" any concrete subclass of SUPAPolicyClause with zero or more
concrete subclasses of the PolicyComponentDecorator object. This
avoids problems of earlier models that resulted in a proliferation
of classes and relationships.
Figure 9 shows these two class subclasses. Note that the decorator A
pattern [11] is used to enable subclasses of the +------------------------------+
SUPAPolicyComponentDecorator class to add their attributes and/or | SUPAPolicyComponentStructure |
behavior to a SUPAPolicyClause (as stated in section 4.3) without +---------------+--------------+
affecting the behavior of other objects from the same class. More / \
specifically, concrete subclasses of the (abstract) I
SUPAPolicyComponentDecorator class can be used to decorate, or I
"wrap", any of the concrete subclasses of the (abstract) +---------------+--------------------+
SUPAPolicyClause class. | |
A | A |
+--------+---------+ +---------------+--------------------+
| | | |
| SUPAPolicyClause | | SUPAPolicyClauseComponentDecorator |
| | | |
+------------------+ +---------------------------+--------+
/ \ 0..n 0..n / \
A |
\ / |
| |
| SUPAPolicyClauseHasDecorator |
+--------------------------------------------------+
A Figure 12. Decorating SUPAPolicyClauses
+------------------------------+ 1..n
| SUPAPolicyComponentStructure +----------------------+
+----------------+-------------+ |
/ \ |
I SUPAHasPolicyComponentDecorators |
I |
+--------------+-----------+ |
I I |
A I A I |
+---------+--------+ +--------------+---------------+ 0..1 |
| | | |/ \ |
| SUPAPolicyClause | | SUPAPolicyComponentDecorator + A -----+
| | | |\ /
+------------------+ +------------------------------+
Figure 9. Subclasses of SUPAPolicyComponentStructure Every SUPAPolicyClause can be made up of a variable number of
SUPAPolicyClauseComponentDecorators, so the multiplicity of the
SUPAPolicyClauseHasDecorator aggregation is 0..n - 0..n. This means
that a SUPAPolicyClause may have zero or more decorating objects,
and that a SUPAPolicyClauseComponentDecorator MAY be associated with
zero or more SUPAPolicyClauses. Note that the "zero" part of this
multiplicity enables SUPAPolicyClauseComponentDecorator objects to
be stored in a PolicyRepository without having to be bound to ability
particular SUPAPolicyClause. The use of the decorator pattern avoids
problems encountered in earlier models, which resulted in a
proliferation of classes and relationships.
Instead of using inheritance to statically create new classes to Instead of using inheritance to statically create new classes to
represent new types of objects, the decorator pattern uses represent new types of objects, the decorator pattern uses
composition to dynamically combine attributes and behavior from composition to dynamically combine attributes and behavior from
existing objects into new objects. This is done by defining an existing objects into new objects. This is done by defining an
interface in SUPAPolicyComponent that all of the subclasses of interface in SUPAPolicyComponent that all of the subclasses of
SUPAPolicyComponent conform to. Since the subclasses are of the SUPAPolicyComponent conform to. Since the subclasses are of the
same type as SUPAPolicyComponent, they all have the same interface. same type as SUPAPolicyComponent, they all have the same interface.
This allows each concrete SUPAPolicyComponentDecorator subclass to This allows each concrete SUPAPolicyClauseComponentDecorator
add its attributes and/or behavior to the concrete subclass of subclass to add its attributes and/or behavior to the concrete
SUPAPolicyClause that it is decorating (or "wrapping"). subclass of SUPAPolicyClause that it is decorating (or "wrapping").
This represents an important design optimization for data models. This represents an important design optimization for data models.
Note that a single SUPAECAPolicyRule can consist of any number of Note that a single SUPAECAPolicyRule can consist of any number of
SUPAPolicyClauses, each of very different types. If inheritance SUPAPolicyClauses, each of very different types. If inheritance
was used, then a subclass AND an aggregation would be required for was used, then a subclass AND an aggregation would be required for
each separate clause that makes up the policy rule. each separate clause that makes up the policy rule.
Clearly, continuing to create subclasses is not practical. Worse, Suppose composite objects are desired (e.g., a new object Foo is
suppose composite objects are desired (e.g., a new object Foo is
made up of existing objects Bar and Baz). If all that was needed made up of existing objects Bar and Baz). If all that was needed
was one attribute of Bar and two of Baz, the developer would still was one attribute of Bar and two of Baz, the developer would still
have to use the entire Bar and Baz classes. This is wasteful and have to use the entire Bar and Baz classes. This is wasteful and
inefficient. In contrast, the decorator pattern enables all, or inefficient. In contrast, the decorator pattern enables all, or
just some, of the attributes and/or behavior of a class to "wrap" just some, of the attributes and/or behavior of a class to "wrap"
another class. This is used heavily in many production systems another class. This is used heavily in many production systems
(e.g., the java.io package) because the result is only the (e.g., the java.io package) because the result is only the
behavior that is required, and no other objects are affected. behavior that is required, and no other objects are affected.
The SUPAPolicyComponentDecorator class hierarchy is used to define SUPAPolicyClauseComponentDecorator is the superclass of five
objects that may be used to construct a SUPAPolicyClause. The subclasses, as shown in Figure 13.
decorator object can add behavior before, and/or after, it
delegates to the object that it is decorating. The subclasses of
SUPAPolicyComponentDecorator provide a very flexible and completely
dynamic mechanism to:
1) add or remove behavior to/from an object
2) ensure that objects are constructed using the minimum amount
of features and functionality required
SUPAPolicyComponentDecorator defines four subclasses, as shown in A
Figure 10. +------------------------------------+
A | SUPAPolicyClauseComponentDecorator |
+------------------------------+ +-----------------+------------------+
| SUPAPolicyComponentDecorator |
+--------------+---------------+
/ \ / \
I I
I I
I I
+------------+-------------+----------------+ +------------+-+-----------+------------------+
I I I I I I I I I
A I I C I I A I I I C I I
+--------+-------+ I +---------+------------+ I +--------+-------+ I I +---------+------------+ I
| SUPAPolicyTerm | I | SUPAPolicyCollection | I | SUPAPolicyTerm | I I | SUPAPolicyCollection | I
+----------------+ I +----------------------+ I +----------------+ I I +----------------------+ I
(for defining I (for defining sets and/or I (for defining I I (for defining sets and/or I
clauses in a I groups of objects) I clauses in a I I groups of objects) I
canonical form) I I canonical form) I I I
I I I +---------------+ I
C I A I C I I A I
+----------------+--------------+ +---------+--------+ +----------------+--------------+ I +---------+--------+
| SUPAGenericDecoratedComponent | | SUPAECAComponent | | SUPAGenericDecoratedComponent | I | SUPAECAComponent |
+-------------------------------+ +------------------+ +-------------------------------+ I +------------------+
(for decorating concrete (for defining reusable (for decorating concrete I (for defining reusable
subclasses of SUPAPolicyClause) event, condition, subclasses of SUPAPolicyClause) I event, condition,
and action objects) I and action objects)
I
A I
+-------------+----------------+
| SUPAPolicyComponentDecorator |
+------------------------------+
(for decorating SUPAPolicyClauseComponentDecorator
objects with SUPAPolicyComponentDecorator objects)
Figure 10. Subclasses of SUPAPolicyComponentDecorator Figure 13. Subclasses of SUPAPolicyClauseComponentDecorator
The SUPAPolicyClauseComponentDecorator class hierarchy is used to
define classes that may be used to construct a SUPAPolicyClause. The
decorator object can add behavior before, and/or after, it
delegates to the object that it is decorating. The subclasses of
SUPAPolicyClauseComponentDecorator provide a very flexible and
completely dynamic mechanism to:
1) add or remove behavior to/from a SUPAPolicyClause object
2) ensure that objects are constructed using the minimum amount
of features and functionality required
If a SUPAEncodedClause is being used, then there is no need to If a SUPAEncodedClause is being used, then there is no need to
use any of the SUPAPolicyComponentDecorator subclasses, since use any of the SUPAPolicyClauseComponentDecorator subclasses, since
the SUPAEncodedClause already completely defines the content of the SUPAEncodedClause already completely defines the content of
the SUPAPolicyClause. the SUPAPolicyClause.
However, if a SUPAEncodedClause is NOT being used, then a However, if a SUPAEncodedClause is NOT being used, then a
SUPAPolicyClause will be constructed using one or more types of SUPAPolicyClause SHOULD be constructed using one or more types of
objects that are each subclasses of SUPAPolicyComponentDecorator. concrete subclasses of SUPAPolicyClauseComponentDecorator.
These four subclasses provide four different ways to construct a These five subclasses provide five different ways to construct a
SUPAPolicyClause: SUPAPolicyClause:
1) SUPAPolicyTerm: as a {variable, operator, value} clause 1) SUPAPolicyTerm: as a {variable, operator, value} clause
2) SUPAEncodedClause: as an encoded object (e.g., to pass YANG 2) SUPAGenericDecoratedComponent: as an encoded object (e.g., to
or CLI code) pass YANG or CLI code)
3) SUPAPolicyCollection: as a collection of objects that 3) SUPAPolicyCollection: as a collection of objects that
requires further processing in order to be made into a requires further processing in order to be made into a
SUPAPolicyClause SUPAPolicyClause
4) SUPAECAComponent: subclasses define reusable Event, 4) SUPAECAComponent: subclasses define reusable Event,
Condition, or Action objects Condition, or Action objects
5) SUPAPolicyComponentDecorator: as a new type of Decorator to
augment any of the above four mechanisms
These four different types of objects can be intermixed. For These four different types of objects can be intermixed. For
example, the first and last types can be combined as follows: example, the first and fourth types can be combined as follows:
Variable == Event.baz (A) Variable == Event.baz (A)
Condition BETWEEN VALUE1 and VALUE2 (B) Condition BETWEEN VALUE1 and VALUE2 (B)
(Event.severity == 'Critical' AND (Event.severity == 'Critical' AND
(SLA.violation == TRUE OR User.class == 'Gold')) (C) (SLA.violation == TRUE OR User.class == 'Gold')) (C)
In the above rules, (A) uses Event.baz to refer to an attribute In the above rules, (A) uses Event.baz to refer to an attribute
of the Event class; (B) defines two different instances of a Value of the Event class; (B) defines two different instances of a Value
class, denoted as Value1 and Value2; (C) uses the nomenclature class, denoted as Value1 and Value2; (C) uses the nomenclature
foo.bar, where foo is the name of a class, and bar is the name of foo.bar, where foo is the name of a class, and bar is the name of
skipping to change at page 37, line 18 skipping to change at page 41, line 31
action clause. action clause.
2) The SUPAPolicyClause can be defined using one or more 2) The SUPAPolicyClause can be defined using one or more
SUPABooleanClauses; each of the three clauses can be SUPABooleanClauses; each of the three clauses can be
defined as either a single SUPABooleanClause, or a defined as either a single SUPABooleanClause, or a
combination of SUPABooleanClauses that are logically combination of SUPABooleanClauses that are logically
ANDed, ORed, and/or NOTed. ANDed, ORed, and/or NOTed.
3) The above two mechanisms can be combined (e.g., the first 3) The above two mechanisms can be combined (e.g., the first
used to define the event clause, and the second used to used to define the event clause, and the second used to
define the condition and action clauses). define the condition and action clauses).
Figure 11 shows the subclasses of SUPAPolicyClause. Figure 14 shows the subclasses of SUPAPolicyClause.
A A
+------------------+ +------------------+
| SUPAPolicyClause | | SUPAPolicyClause |
+--------+---------+ +--------+---------+
/ \ / \
I I
I I
I I
+---------------+-------------+ +---------------+-------------+
I I I I
A I C I A I C I
+--------+----------+ +----------+--------+ +--------+----------+ +----------+--------+
| SUPABooleanClause | | SUPAEncodedClause | | SUPABooleanClause | | SUPAEncodedClause |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
Figure 11. Subclasses of SUPAPolicyClause Figure 14. Subclasses of SUPAPolicyClause
SUPABooleanClause is defined in the EPRIM, and is used to SUPABooleanClause (see Section 6.7) is defined in the EPRIM, and is
construct Boolean clauses that collectively make up a used to construct Boolean clauses that collectively make up a
SUPAPolicyClause. It is abstract, so that the composite pattern SUPAPolicyClause. It is abstract, so that the composite pattern
can be applied to it, which enables hierarchies of Boolean can be applied to it, which enables hierarchies of Boolean
clauses to be created. SUPAEncodedClause (see section 6.7) is clauses to be created. SUPAEncodedClause (see section 5.6) is
used to encode the content of a SUPAPolicyClause as an attribute used to encode the content of a SUPAPolicyClause as an attribute
(instead of reusable objects). (instead of reusable objects).
4.4.5. SUPAPolicySources 4.4.5. SUPAPolicySources
A SUPAPolicySource is a set of managed entities that authored, A SUPAPolicySource is a set of managed entities that authored,
or are otherwise responsible for, this SUPAPolicy. Note that a or are otherwise responsible for, this SUPAPolicy. Note that a
SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its
primary use is for auditability, authorization policies, and primary use is for auditability, authorization policies, and
other applications of deontic and/or alethic logic. other applications of deontic and/or alethic logic.
SUPAPolicyStructure defines four relationships. Two of these The SUPAHasPolicySource aggregation defines the set of
(SUPAHasPolicySource and SUPAHasPolicyTarget), which are both SUPAPolicySource objects that are sources for a given SUPAPolicy
aggregations, relate a SUPAPolicyStructure to a SUPAPolicySource (as defined by a concrete subclass of SUPAPolicyStructure). Since
and a SUPAPolicyTarget, respectively. Since SUPAECAPolicyRule is SUPAECAPolicyRule is a subclass of SUPAPolicyStructure, it (and
a subclass of SUPAPolicyStructure, it (and its subclasses) inherit its subclasses) inherit this aggregation. This enables a set of
both of these aggregations. This enables SUPAPolicySources and/or SUPAPolicySource objects to be attached to a particular
SUPAPolicyTargets to be attached to SUPAECAPolicyRules (but NOT to SUPAECAPolicyRule object.
components of a SUPAPolicy).
Figure 12 shows how SUPAPolicySources and SUPAPolicyTargets are Figure 15 shows how SUPAPolicySources and SUPAPolicyTargets are
attached to a SUPAPolicy. Note that both of these aggregations attached to a SUPAPolicy. Note that both of these aggregations
are defined as optional, since their multiplicity is 0..n - 0..n. are defined as optional, since their multiplicity is 0..n - 0..n.
In addition, both of these aggregations are realized as In addition, both of these aggregations are realized as
association classes, in order to be able to control which association classes, in order to be able to control which
SUPAPolicySources and SUPAPolicyTargets are attached to a given SUPAPolicySources and SUPAPolicyTargets are attached to a given
SUPAECAPolicyRule. SUPAECAPolicyRule.
A A
+------------------+ +------------------+
| SUPAPolicyObject | | SUPAPolicyObject |
+--------+---------+ +--------+---------+
/ \ / \
I I
I I
I
+--------------+-----+---------------------+ +--------------+-----+---------------------+
I I I I I I
A I C I C I A I C I C I
+-----------+---------+ +-------+--------+ +--------+-------+ +-----------+---------+ +-------+--------+ +--------+-------+
| SUPAPolicyStructure | |SUPAPolicySource| |SUPAPolicyTarget| | SUPAPolicyStructure | |SUPAPolicySource| |SUPAPolicyTarget|
+------+-------+------+ +----------+-----+ +----------+-----+ +------+-------+------+ +----------+-----+ +----------+-----+
0..n / \ / \ 0..n 0..n / \ 0..n / \ 0..n / \ / \ 0..n 0..n / \ 0..n / \
A A | | A A | |
\ / \ / | | \ / \ / | |
| | | | | | | |
| | | | | | | |
| +--------------------+ | | +--------------------+ |
| SUPAHasPolicySource | | SUPAHasPolicySource |
| | | |
+-------------------------------------------------+ +-------------------------------------------------+
SUPAHasPolicyTarget SUPAHasPolicyTarget
Figure 12. ECAPolicyRules, SUPAPolicySources, and PolicyTargets Figure 15. ECAPolicyRules, SUPAPolicySources, and PolicyTargets
A SUPAPolicySource MAY be mapped to a role (e.g., using the A SUPAPolicySource MAY be mapped to a role (e.g., using the
role-object pattern [11]); this indirection makes the system less role-object pattern [11]); this indirection makes the system less
fragile, as entities can be transparently added or removed from fragile, as entities can be transparently added or removed from
the role definition without adversely affecting the definition of the role definition without adversely affecting the definition of
the SUPAPolicy. Note that SUPAPolicyRole is a subclass of the SUPAPolicy. Note that SUPAPolicyRole is a subclass of
SUPAPolicyMetadata. SUPAPolicyMetadata.
4.4.6. SUPAPolicyTargets 4.4.6. SUPAPolicyTargets
skipping to change at page 39, line 25 skipping to change at page 43, line 32
SUPAPolicyTarget. For example, a managed entity may not be SUPAPolicyTarget. For example, a managed entity may not be
in a state that enables SUPAPolicies to be applied to it; in a state that enables SUPAPolicies to be applied to it;
hence, in this case, it MUST NOT assume the role of a hence, in this case, it MUST NOT assume the role of a
SUPAPolicyTarget SUPAPolicyTarget
2) A SUPAPolicyTarget must be able to: 2) A SUPAPolicyTarget must be able to:
a) process (either directly or with the aid of a proxy) a) process (either directly or with the aid of a proxy)
SUPAPolicies, or SUPAPolicies, or
b) receive the results of a processed SUPAPolicy and b) receive the results of a processed SUPAPolicy and
apply those results to itself. apply those results to itself.
Figure 12 showed how SUPAPolicyTargets are attached to Figure 15 showed how SUPAPolicyTargets are attached to
SUPAECAPolicyRules. SUPAECAPolicyRules.
The SUPAHasPolicyTarget aggregation defines the set of
SUPAPolicyTarget objects that are targets for (e.g., will be acted
on) by a given SUPAPolicy (as defined by a concrete subclass of
SUPAPolicyStructure). Since SUPAECAPolicyRule is a subclass of
SUPAPolicyStructure, it (and its subclasses) inherit this
aggregation. This enables a set of SUPAPolicyTarget objects to be
attached to a particular SUPAECAPolicyRule object.
A SUPAPolicyTarget MAY be mapped to a role (e.g., using the A SUPAPolicyTarget MAY be mapped to a role (e.g., using the
role-object pattern [11]); this indirection makes the system less role-object pattern [11]); this indirection makes the system less
fragile, as entities can be transparently added or removed from fragile, as entities can be transparently added or removed from
the role definition without adversely affecting the definition of the role definition without adversely affecting the definition of
the SUPAPolicy. Note that SUPAPolicyRole is a subclass of the SUPAPolicy. Note that SUPAPolicyRole is a subclass of
SUPAPolicyMetadata. SUPAPolicyMetadata.
4.4.7. Policy Metadata 4.4.7. Policy Metadata
Metadata is, literally, data about data. As such, it can be Metadata is, literally, data about data. As such, it can be
skipping to change at page 41, line 7 skipping to change at page 45, line 28
4.4.7.2. Design Approach 4.4.7.2. Design Approach
The goal of the GPIM is to enable metadata to be attached to any The goal of the GPIM is to enable metadata to be attached to any
subclass of SUPAPolicyObject that requires it. Since this is a subclass of SUPAPolicyObject that requires it. Since this is a
system intended for policy-based management, it therefore makes system intended for policy-based management, it therefore makes
sense to be able to control which metadata is attached to which sense to be able to control which metadata is attached to which
policies dynamically (i.e., at runtime). policies dynamically (i.e., at runtime).
One solution is to use the Policy Pattern [1], [2], [6], [12]. One solution is to use the Policy Pattern [1], [2], [6], [12].
This pattern was built to work with management systems whose This pattern was built to work with management systems whose
actions were dependent upon context. The Policy Pattern works as actions were dependent upon context. The Policy Pattern is shown
follows: in Figure 16, and works as follows:
o Context is derived from all applicable system inputs (e.g.,
OAMP data from network elements, business goals, time of
day, geo-location, etc.).
o Context is then used to select a working set of Policies.
o Policies are then used to define behavior at various
control points in the system.
o One simple type of control point is an association class.
Since the association class represents the semantics of how
two classes are related to each other, then
o ECAPolicyRule actions can be used to change the attribute
values, methods, and relationships of the association
class
o This has the affect of changing how the two classes are
related to each other
o Finally, as context changes, the working set of policies
change, enabling the behavior to be adjusted to follow
changes in context (according to appropriate business goals
and other factors, of course) in a closed loop manner.
Conceptually, this is accomplished as shown in Figure 13 below.
Defines Defines
+----------+ Behavior +------------+ +----------+ Behavior +------------+
| Policies +----------------+ | SUPAPolicy | | Policies +----------------+ | SUPAPolicy |
+----+-----+ 1..n | +------+-----+ +----+-----+ 1..n | +------+-----+
0..n / \ | / \ 0..n 0..n / \ | / \ 0..n
| | A | | A
| | \ / | | \ /
| 1..n \ / | | 1..n \ / |
| +-----------+--------------+ | | +-----------+--------------+ |
skipping to change at page 41, line 55 skipping to change at page 45, line 55
| | | | | |
| +-------------------->+ | +-------------------->+
| Applies | | Applies |
/ \ Behavior | / \ Behavior |
A | A |
0..n \ / \ / 0..n 0..n \ / \ / 0..n
+----+-----+ +--------+---------+ +----+-----+ +--------+---------+
| Context | |SUPAPolicyMetadata| | Context | |SUPAPolicyMetadata|
+----------+ +------------------+ +----------+ +------------------+
Figure 13. Context-Aware Policy Rules Figure 16. Context-Aware Policy Rules
o Context is derived from all applicable system inputs (e.g.,
OAMP data from network elements, business goals, time of
day, geo-location, etc.).
o Context is then used to select a working set of Policies.
o Policies are then used to define behavior at various
control points in the system.
o One simple type of control point is an association class.
Since the association class represents the semantics of how
two classes are related to each other, then
o ECAPolicyRule actions can be used to change the attribute
values, methods, and relationships of the association
class
o This has the affect of changing how the two classes are
related to each other
o Finally, as context changes, the working set of policies
change, enabling the behavior to be adjusted to follow
changes in context (according to appropriate business goals
and other factors, of course) in a closed loop manner.
4.4.7.2.1. Policies and Actors 4.4.7.2.1. Policies and Actors
The Policy Continuum ([1] [5] [10] [12]) was defined to associate The Policy Continuum ([1] [5] [10] [12]) was defined to associate
different actors with different policies at different levels of different actors with different policies at different levels of
business and/or technical specificity. Context-aware policy rules, business and/or technical specificity. Context-aware policy rules,
and the Policy Pattern, were defined to realize this association. and the Policy Pattern, were defined to realize this association.
Four important functions related to the lifecycle of policies are Four important functions related to the lifecycle of policies are
design, implementation, deployment, and execution. There are many design, implementation, deployment, and execution. There are many
skipping to change at page 43, line 52 skipping to change at page 48, line 21
respectively, of a policy rule and/or its components. respectively, of a policy rule and/or its components.
The SUPAPolicyStructure defines an attribute, supaPolDeployStatus, The SUPAPolicyStructure defines an attribute, supaPolDeployStatus,
(see section 5.3.1.3.) that SUPAPolicyMetadata objects can (see section 5.3.1.3.) that SUPAPolicyMetadata objects can
use to get and set the deployment and execution status of a use to get and set the deployment and execution status of a
SUPAPolicy. This allows metadata to be used to alter the SUPAPolicy. This allows metadata to be used to alter the
deployment and/or execution state of a policy (or a set of deployment and/or execution state of a policy (or a set of
policy components) without having to affect other parts of the policy components) without having to affect other parts of the
policy-based management system. The supaPolDeployStatus attribute policy-based management system. The supaPolDeployStatus attribute
indicates that this SUPAPolicy can or cannot be deployed. If it indicates that this SUPAPolicy can or cannot be deployed. If it
cannot be deployed. Similarly, the supaPolExecStatus attribute cannot be deployed.
is used to indicate if a particular SUPAPolicy has executed, is
currently executing, or is ready to execute, and whether or not
the execution of that SUPAPolicy had any failures.
The reverse is also true (and hence, forms a closed-loop system The reverse is also true (and hence, forms a closed-loop system
controlled by metadata). For example, if the set of deployed controlled by metadata). For example, if the set of deployed
SUPAPolicies are SUPAECAPolicyRules, then when the actions of SUPAPolicies are SUPAECAPolicyRules, then when the actions of
these SUPAECAPolicyRules are executed, the overall context has these SUPAECAPolicyRules are executed, the overall context has
changed (see section 4.4.7.2). The context manager could then changed (see section 4.4.7.2). The context manager could then
change attribute values (directly or indirectly) in the change attribute values (directly or indirectly) in the
SUPAPolicyMetadataDetail association class. This class represents SUPAPolicyMetadataDetail association class. This class represents
the behavior of the SUPAHasPolicyMetadata aggregation, which is the behavior of the SUPAHasPolicyMetadata aggregation, which is
used to define which SUPAPolicyMetadata can be attached to which used to define which SUPAPolicyMetadata can be attached to which
SUPAPolicy objet in this particular context. For example, the SUPAPolicy objet in this particular context. For example, the
access privileges of a policy and/or policy component could be access privileges of a policy and/or policy component could be
changed dynamically, according to changes in context. changed dynamically, according to changes in context.
By using the decorator pattern on SUPAPolicyMetadata, any number By using the decorator pattern on SUPAPolicyMetadata, any number
of SUPAPolicyMetadata objects (or their attributes, etc.) can be of SUPAPolicyMetadata objects (or their attributes, etc.) can be
wrapped around a concrete subclass of SUPAPolicyMetadata. This is wrapped around a concrete subclass of SUPAPolicyMetadata. This is
shown in Figure 14 below. shown in Figure 17 below.
4.4.7.3. Structure of SUPAPolicyMetadata 4.4.7.3. Structure of SUPAPolicyMetadata
SUPAPolicyMetadata also uses the decorator pattern to provide an SUPAPolicyMetadata also uses the decorator pattern to provide an
extensible framework for defining metadata to attach to SUPAPolicy extensible framework for defining metadata to attach to SUPAPolicy
subclasses. Its two principal subclasses are subclasses. Its two principal subclasses are
SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. The SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. The
former is used to define concrete subclasses of SUPAPolicyMetadata former is used to define concrete subclasses of SUPAPolicyMetadata
that are attached at runtime to SUPAPolicy subclasses, while the that are attached at runtime to SUPAPolicy subclasses, while the
latter is used to define concrete objects that represent reusable latter is used to define concrete objects that represent reusable
skipping to change at page 45, line 5 skipping to change at page 49, line 27
the data in that class) the data in that class)
2. defining a class means defining its attributes, methods, and 2. defining a class means defining its attributes, methods, and
relationships at a particular place in the hierarchy; this relationships at a particular place in the hierarchy; this
means that defining a relationship between a class A and means that defining a relationship between a class A and
another class B SHOULD only be done if all of the subclasses another class B SHOULD only be done if all of the subclasses
of B can use the attributes, methods, and relationships of A of B can use the attributes, methods, and relationships of A
(e.g., in the above example, defining a relationship between (e.g., in the above example, defining a relationship between
an Identification Object and a superclass of a router class an Identification Object and a superclass of a router class
is not appropriate, since routers do not use Passports) is not appropriate, since routers do not use Passports)
Therefore, an association class is used to define the semantics
of the SUPAHasPolicyMetadata aggregation. This follows the strategy
defined in Section 4.2.2. Figure 17 illustrates this approach. The
SUPAHasPolicyMetadataDetail association class contains attributes
that define which SUPAPolicyMetadata objects can be aggregated by
which SUPAPolicyObjects. This also enables SUPAPolicies to be
defined that get and set the values of these attributes. (Note that
for this approach to work, the association class is defined as a
concrete class.) The multiplicity of the SUPAHasPolicyMetadata
aggregation is defined as 0..n - 0..n, which makes this approach
optional.
Since a class encapsulates attributes, methods, and behavior,
defining the Identification Object in the above example as a type
of SUPAPolicyMetadata object enables the decorator pattern to be
used to attach all or part of that object to other objects that
need it.
A A
+------------------+ +------------------+
| SUPAPolicyObject | | SUPAPolicyObject |
+--------+---------+ +--------+---------+
/ \ 0..n / \ 0..n
A A
\ / \ /
| A | A
| 0..n +--------------------+ | 0..n +--------------------+
| SUPAHasPolicyMetadata \| | | SUPAHasPolicyMetadata \| |
+-------------+-----------------+ SUPAPolicyMetadata | +-------------+-----------------+ SUPAPolicyMetadata |
^ /| | ^ /| |
| +------+------+------+ | +------+------+------+
C | / \ | 1..n C | / \ | 1..n
+-------------+---------------+ I | +-------------+---------------+ I |
1..n | | I | 0..n | | I |
+----------+ SUPAHasPolicyMetadataDetail | I | +----------+ SUPAHasPolicyMetadataDetail | I |
| | | I | | | | I |
| +-----------------------------+ I | | +-----------------------------+ I |
| I | | I |
| (gets/sets values of attributes and/or I |
| methods of the SUPAHasPolicyMetadataDetail I |
| class; this affects which SUPAPolicyMetadata I |
| objects can be attached to which policies I |
| and policy components) I |
| I |
| C I | | C I |
| +----------------------------+ I | | 0..n +----------------------------+ I |
| | | I |
+----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+ | +----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+ |
| | I |
+----------------------------+ I | +----------------------------+ I |
I | I |
A I | A I |
+-----------------------------+ I | +-----------------------------+ I |
| | I |
| SUPAPolicyMetadataDecorator +IIIIIIIII+ | | SUPAPolicyMetadataDecorator +IIIIIIIII+ |
| | |
+-------+--------------+------+ | +-------+--------------+------+ |
/ \ / \ 0..1 | / \ / \ 0..1 |
I A | I A |
I \ / | I \ / |
I | | I | |
subclasses for adding | | subclasses for adding | |
behavior to policies +-----------------------+ behavior to policies +-----------------------+
and policy components SUPAHasMetadataDecorator and policy components SUPAHasMetadataDecorator
Figure 14. SUPAPolicyMetadata Subclasses and Relationships Figure 17. SUPAPolicyMetadata Association Class Relationships
Since a class encapsulates attributes, methods, and behavior,
defining the Identification Object in the above example as a type
of SUPAPolicyMetadata object enables the decorator pattern to be
used to attach all or part of that object to other objects that
need it.
Figure 15 shows a portion of the SUPAPolicyMetadata hierarchy. Figure 18 shows a relevant portion of the SUPAPolicyMetadata
hierarchy. SUPAPolicyConcreteMetadata is a concrete class that
subclasses of the SUPAPolicyMetadataDecorator class can wrap.
Two such subclasses, SUPAPolicyAccessMetadataDef and
SUPAPolicyVersionMetadataDef, are shown in Figure 18. This
enables access control and version information to be added
statically (at design time) or dynamically (at runtime) to
SUPAPolicyConcreteMetadata; this enables metadata-driven systems
to adjust the behavior of the management system to changes in
context, business rules, services given to end-users, and other
similar factors. This is discussed more in sections 5.18 - 5.20.
A A
+--------------------+ +--------------------+
| | SUPAHasMetadataDecorator | | SUPAHasMetadataDecorator
| SUPAPolicyMetadata +-------------------+ | SUPAPolicyMetadata +-------------------+
| | 1..n | | | 1..n |
+---------+----------+ | +---------+----------+ |
I | I |
I | I |
I | I |
skipping to change at page 46, line 39 skipping to change at page 51, line 31
+------------+----------------+ +------------+----------------+
I I
+------------------------------+--------+ +------------------------------+--------+
I I I I
I I I I
C I C I C I C I
+---------------+-------------+ +---------------------+--------+ +---------------+-------------+ +---------------------+--------+
| SUPAPolicyAccessMetadataDef | | SUPAPolicyVersionMetadataDef | | SUPAPolicyAccessMetadataDef | | SUPAPolicyVersionMetadataDef |
+-----------------------------+ +------------------------------+ +-----------------------------+ +------------------------------+
Figure 15. SUPAPolicyMetadata Subclasses and Relationships Figure 18. SUPAPolicyMetadata Subclasses and Relationships
Figure 15 shows a relevant portion of the SUPAPolicyMetadata
hierarchy. SUPAPolicyConcreteMetadata is a concrete class that
subclasses of the SUPAPolicyMetadataDecorator class can wrap.
Two such subclasses, SUPAPolicyAccessMetadataDef and
SUPAPolicyVersionMetadataDef, are shown in Figure 15. This
enables access control and version information to be added
statically (at design time) or dynamically (at runtime) to
SUPAPolicyConcreteMetadata; this enables metadata-driven systems
to adjust the behavior of the management system to changes in
context, business rules, services given to end-users, and other
similar factors. This is discussed more in sections 5.18 - 5.20.
4.5. Advanced Features
This section will be completed in the next revision of this
document.
4.5.1. Policy Grouping
This section will be completed in the next revision of this
document.
4.5.2. Policy Rule Nesting
This section will be completed in the next revision of this
document.
5. GPIM Model 5. GPIM Model
This section defines the classes, attributes, and relationships of This section defines the classes, attributes, and relationships of
the GPIM. the GPIM.
5.1. Overview 5.1. Overview
The overall class hierarchy is shown in Figure 16; section numbers The overall class hierarchy is shown in Figure 19.
are appended after each class.
(Class of another model that SUPA is integrating into) (Class of another model that SUPA is integrating into)
| |
+---SUPAPolicyObject (5.2) +---SUPAPolicyObject (Sec 5.2)
| | |
| +---SUPAPolicyStructure (5.3) +---SUPAPolicyStructure (Sec 5.3)
| | |
| +---SUPAPolicyComponentStructure (5.4) +---SUPAPolicyComponentStructure (Sec 5.4)
| | | | |
| | +---SUPAPolicyClause (5.5) | +---SUPAPolicyClause (Sec 5.5)
| | | | | | |
| | | +---SUPAEncodedClause (5.6) | | +---SUPAEncodedClause (Sec 5.6)
| | | | |
| | +---SUPAPolicyComponentDecorator (5.7) | +---SUPAPolicyClauseComponentDecorator (Sec 5.7)
| | | | |
| | +---SUPAPolicyTerm (5.8) | +---SUPAPolicyTerm (Sec 5.8)
| | | | | | |
| | | +---SUPAPolicyVariable (5.9) | | +---SUPAPolicyVariable (Sec 5.9)
| | | | | | |
| | | +---SUPAPolicyOperator (5.10) | | +---SUPAPolicyOperator (Sec 5.10)
| | | | | | |
| | | +---SUPAPolicyValue (5.11) | | +---SUPAPolicyValue (Sec 5.11)
| | | | |
| | +---SUPAGenericDecoratedComponent (5.12) | +---SUPAGenericDecoratedComponent (Sec 5.12)
| | | | |
| | +---SUPAPolicyCollection (5.13) | +---SUPAPolicyCollection (Sec 5.13)
| | | |
| +---SUPAPolicySource (5.14) | +---SUPAPolicyComponentDecorator (Sec 5.14)
| | |
| +---SUPAPolicyTarget (5.15) +---SUPAPolicySource (Sec 5.15)
|
+---SUPAPolicyTarget (Sec 5.16)
(Class of another model that SUPAPolicyMetadata is integrating into) (Class of another model that SUPAPolicyMetadata is integrating into)
| |
+---SUPAPolicyMetadata (5.16) +---SUPAPolicyMetadata (Sec 5.17)
| |
+---SUPAPolicyConcreteMetadata (5.17) +---SUPAPolicyConcreteMetadata (Sec 5.18)
| |
+---SUPAPolicyMetadataDecorator (5.18) +---SUPAPolicyMetadataDecorator (Sec 5.19)
| |
+---SUPAPolicyAccessMetadataDef (5.19) +---SUPAPolicyAccessMetadataDef (Sec 5.20)
| |
+---SUPAPolicyVersionMetadataDef (5.20) +---SUPAPolicyVersionMetadataDef (5.20)
Figure 16: Main Classes of the GPIM Figure 19. Main Classes of the GPIM
SUPAPolicy is the root of the SUPA class hierarchy. For SUPAPolicy is the root of the SUPA class hierarchy. For
implementations, it is assumed that SUPAPolicy is subclassed from implementations, it is assumed that SUPAPolicy is subclassed from
a class from another model. Note that SUPAPolicyMetadata MAY be a class from another model. Note that SUPAPolicyMetadata MAY be
subclassed from the same or (preferably) a different class in the subclassed from the same or (preferably) a different class in the
external model. external model.
Classes, attributes, and relationships that are marked as Classes, attributes, and relationships that are marked as
"mandatory" MUST be part of a conformant implementation (i.e., a "mandatory" MUST be part of a conformant implementation (i.e., a
schema MUST contain these entities). This does not mean that these schema MUST contain these entities). This does not mean that these
entities must be instantiated; rather it means that they must be entities must be instantiated; rather it means that they must be
able to be instantiated. Classes, attributes, and relationships able to be instantiated. Classes, attributes, and relationships
that are marked as "optional" MAY be part of a conformant that are marked as "optional" MAY be part of a conformant
implementation. implementation. Note that the Single Responsibility Principle [14]
mandates that subclasses should not change inherited attributes.
Unless otherwise stated, all classes (and attributes) defined in Unless otherwise stated, all classes (and attributes) defined in
this section were abstracted from DEN-ng [2], and a version of this section were abstracted from DEN-ng [2].
them are in the process of being added to [5]. However, the work
in [5] has been put on hold, and the names of many of the classes,
attributes, and relationships are slightly different.
5.2. The Abstract Class "SUPAPolicyObject" 5.2. The Abstract Class "SUPAPolicyObject"
This is a mandatory abstract class. Figure 17 shows the This is a mandatory abstract class. Figure 20 shows the
SUPAPolicyObject class, and its four subclasses. SUPAPolicyObject class, and its four subclasses.
A 0..n 0..n A A 0..n 0..n A
+----------------+/ \ \+------------------+ +----------------+/ \ \+------------------+
|SUPAPolicyObject+ A --------------------------+SUPAPolicyMetadata| |SUPAPolicyObject+ A --------------------------+SUPAPolicyMetadata|
+--------+-------+\ / SUPAHasPolicyMetadata /+------------------+ +--------+-------+\ / SUPAHasPolicyMetadata /+------------------+
/ \ / \
I I
I I
+-----------------+----------------+-----------+ +-----------------+----------------+-----------+
skipping to change at page 49, line 56 skipping to change at page 53, line 54
+------------------------------+ I I +------------------------------+ I I
C I I C I I
+---------+--------+ I +---------+--------+ I
| SUPAPolicyTarget | I | SUPAPolicyTarget | I
+------------------+ I +------------------+ I
C I C I
+----------+-------+ +----------+-------+
| SUPAPolicySource | | SUPAPolicySource |
+------------------+ +------------------+
Figure 17. SUPAPolicyObject and Its Subclasses Figure 20. SUPAPolicyObject and Its Subclasses
This class is the root of the SUPA class hierarchy. It defines the This class is the root of the SUPA class hierarchy. It defines the
common attributes and relationships that all SUPA subclasses common attributes and relationships that all SUPA subclasses
inherit. inherit.
A SUPAPolicyObject MAY be qualified by a set of zero or more A SUPAPolicyObject MAY be qualified by a set of zero or more
SUPAPolicyMetadata objects. This is provided by the SUPAPolicyMetadata objects. This is provided by the
SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This
enables the semantics of the SUPAPolicyObject to be more enables the semantics of the SUPAPolicyObject to be more
completely specified. completely specified.
skipping to change at page 52, line 46 skipping to change at page 56, line 46
done to the SUPA class hierarchy that are NOT present in [5]. done to the SUPA class hierarchy that are NOT present in [5].
For this release, the only official type of policy that is For this release, the only official type of policy that is
supported is the event-condition-action (ECA) type of policy rule. supported is the event-condition-action (ECA) type of policy rule.
However, the structure of the SUPA hierarchy is defined to However, the structure of the SUPA hierarchy is defined to
facilitate adding new types of rules later. facilitate adding new types of rules later.
A SUPAPolicy may take the form of an individual policy or a set A SUPAPolicy may take the form of an individual policy or a set
of policies. This requirement is supported by applying the of policies. This requirement is supported by applying the
composite pattern to subclasses of the SUPAPolicyStructure class, composite pattern to subclasses of the SUPAPolicyStructure class,
as shown in Figure 5. In this document, this is done for the as shown in Figure 8. In this document, this is done for the
SUPAECAPolicyRule subclass, and results in two subclasses: SUPAECAPolicyRule subclass, and results in two subclasses:
SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and
SUPAECAPolicyRuleComposite (for defining hierarchies of policies). SUPAECAPolicyRuleComposite (for defining hierarchies of policies).
Note that there is no need for a "match strategy attribute" that Note that there is no need for a "match strategy attribute" that
some models [RFC3460], [4], [6] have; this is because the some models [RFC3460], [4], [6] have; this is because the
SUPAPolicyStructure class is used just for containment. Hence, the SUPAPolicyStructure class is used just for containment. Hence, the
containers themselves serve as the scoping component for nested containers themselves serve as the scoping component for nested
policies. policies.
skipping to change at page 55, line 8 skipping to change at page 59, line 8
attempted, and that SUPAPolicies that otherwise would have been attempted, and that SUPAPolicies that otherwise would have been
executed are ignored. A value of 3 means that execution is stopped, executed are ignored. A value of 3 means that execution is stopped,
and rollback is attempted for ONLY the SUPAPolicy that failed to and rollback is attempted for ONLY the SUPAPolicy that failed to
execute correctly. A value of 4 means that execution is stopped, but execute correctly. A value of 4 means that execution is stopped, but
no actions are rolled back. A value of 5 means that the failure is no actions are rolled back. A value of 5 means that the failure is
ignored, and execution continues. ignored, and execution continues.
5.3.2. SUPAPolicyStructure Relationships 5.3.2. SUPAPolicyStructure Relationships
The SUPAPolicyStructure class owns four relationships, which are The SUPAPolicyStructure class owns four relationships, which are
defined in the following subsections. defined in the following subsections. It also inherits the
SUPAHasPolicyMetadata aggregation (see section 5.17.2.1.).
5.3.2.1. The Aggregation "SUPAHasPolicySource" 5.3.2.1. The Aggregation "SUPAHasPolicySource"
This is an optional aggregation, and defines the set of This is an optional aggregation, and defines the set of
SUPAPolicySource objects that are attached to this particular SUPAPolicySource objects that are attached to this particular
SUPAPolicyStructure object. The semantics of this aggregation SUPAPolicyStructure object. The semantics of this aggregation
are defined by the SUPAHasPolicySourceDetail association class. are defined by the SUPAHasPolicySourceDetail association class.
PolicySource objects are used for authorization policies, as well PolicySource objects are used for authorization policies, as well
as to enforce deontic and alethic logic. as to enforce deontic and alethic logic.
skipping to change at page 57, line 12 skipping to change at page 61, line 12
SUPAPolicyStructure objects may be associated with this given SUPAPolicyStructure objects may be associated with this given
SUPAPolicyStructure object. SUPAPolicyStructure object.
5.3.2.6. The Association Class "SUPAHasPolExecFailTakeActionDetail" 5.3.2.6. The Association Class "SUPAHasPolExecFailTakeActionDetail"
This is an optional concrete class that defines the semantics for This is an optional concrete class that defines the semantics for
the SUPAHasPolExecFailTakeAction association. The attributes and/or the SUPAHasPolExecFailTakeAction association. The attributes and/or
relationships of this association class can be used to determine relationships of this association class can be used to determine
which policy action objects are executed in response to a failure which policy action objects are executed in response to a failure
of the SUPAPolicyStructure object instance that owns this of the SUPAPolicyStructure object instance that owns this
association. The association relates the policy actions from one association. The association defines the set of policy actions from
SUPAPolicyStructure B to be executed if a SUPAPolicyStructure A one SUPAPolicyStructure object to be executed if another
fails to execute properly. Figure 18 illustrates this approach. SUPAPolicyStructure object fails to execute properly. Figure 21
illustrates this approach.
A A
+---------------------------+ 0..n +---------------------------+ 0..n
| +---------------------------------+ | +---------------------------------+
| | SUPAHasPolExecFailTakeAction | | | SUPAHasPolExecFailTakeAction |
| SUPAPolicyStructure |/ | | SUPAPolicyStructure |/ |
| + --------------+-----------------+ | + --------------+-----------------+
| |\ ^ | |\ ^
+---------------------------+ 1..n | +---------------------------+ 1..n |
| |
C | C |
+------------------+-----------------+ +------------------+-----------------+
| SUPAHasPolExecFailTakeActionDetail | | SUPAHasPolExecFailTakeActionDetail |
+------------------------------------+ +------------------------------------+
Figure 18. SUPAHasPolExecFailTakeAction Association Figure 21. SUPAHasPolExecFailTakeAction Association
5.3.2.6.1. The Attribute "supaPolExecFailActionEncoding" 5.3.2.6.1. The Attribute "supaPolExecFailActionEncoding"
This is an optional enumerated, non-negative integer attribute This is an optional enumerated, non-negative integer attribute
that defines how to find the set of SUPAPolicyActions contained that defines how to find the set of SUPAPolicyActions contained
in each element of the supaPolExecFailTakeActionName class in each element of the supaPolExecFailTakeActionName class
attribute. Values include: attribute. Values include:
0: error 0: error
1: init 1: init
skipping to change at page 59, line 13 skipping to change at page 63, line 13
be aggregated by this particular SUPAPolicyStructure object. be aggregated by this particular SUPAPolicyStructure object.
5.3.2.8. The Association Class "SUPAHasPolicyClauseDetail" 5.3.2.8. The Association Class "SUPAHasPolicyClauseDetail"
This is an optional abstract association class, and defines the This is an optional abstract association class, and defines the
semantics of the SUPAHasPolicyClause aggregation. The attributes semantics of the SUPAHasPolicyClause aggregation. The attributes
and/or relationships of this association class can be used to and/or relationships of this association class can be used to
determine which SUPAPolicyClauses are aggregated by which determine which SUPAPolicyClauses are aggregated by which
SUPAPolicyStructure objects. SUPAPolicyStructure objects.
Attributes will be added to this class at a later time.
5.4. The Abstract Class "SUPAPolicyComponentStructure" 5.4. The Abstract Class "SUPAPolicyComponentStructure"
This is a mandatory abstract class that is the superclass of all This is a mandatory abstract class. It is the superclass of all
objects that represent different types of components of a objects that represent different types of components of a
SUPAPolicy. Different types of policies have different types of SUPAPolicy. Different types of policies have different types of
structural components. This is accommodated by defining two generic structural components. This is accommodated by defining two generic
subclasses, called SUPAPolicyClause and SUPAPolicyComponentDecorator, abstract subclasses, called SUPAPolicyClause and
which are common to different policy types. These two classes SUPAPolicyClauseComponentDecorator, which are both common to
represent convenient control points for defining characteristics different policy types. These two classes represent convenient
and behavior that are common to objects that serve as components of control points for defining characteristics and behavior that are
a SUPAPolicy. common to objects that serve as components of a SUPAPolicy.
SUPAPolicyClause defines a basic building block for writing SUPAPolicyClause defines a basic building block for writing
parts of a SUPAPolicy. It is analogous to a clause in a sentence. parts of a SUPAPolicy. It is analogous to a clause in a sentence.
For example, in an ECA Policy Rule, the Event, Condition, and Action For example, in an ECA Policy Rule, the Event, Condition, and Action
clauses are each made up of at least one (subclass of a) clauses are each made up of at least one (concrete subclass of a)
SUPAPolicyClause. Similalry, declarative Policy Rules can also be SUPAPolicyClause. Similalry, declarative Policy Rules can also be
defined using (its own subclasses of) SUPAPolicyClauses. This class defined using (its own subclasses of) SUPAPolicyClauses. This class
is defined in section 5.5. is defined in section 5.5.
SUPAPolicyComponentDecorator is used to implement the decorator SUPAPolicyClauseComponentDecorator implements the decorator
pattern [11]. The decorator pattern enables all or part of one or pattern [11]. The decorator pattern enables all or part of one or
more objects to "wrap" another concrete object. This enables the more objects to "wrap" another concrete object (as described in
definition of an extensible set of subclasses that can augment the Section 4.2.1.2). This enables the definition of an extensible set
definition of a SUPAPolicyClause. This class is defined in of subclasses that can augment the definition of a SUPAPolicyClause.
section 5.7. This class is defined in section 5.7.
Note that there are significant differences between the definition Note that there are significant differences between the definition
of the SUPAPolicyComponentStructure class, and its attributes and of the SUPAPolicyComponentStructure class, and its attributes and
relationships, and the definition of the corresponding class (and relationships, and the definition of the corresponding class (and
its attributes and relationships) in [5]. its attributes and relationships) in [5].
5.4.1. SUPAPolicyComponentStructure Attributes 5.4.1. SUPAPolicyComponentStructure Attributes
No attributes are currently defined for the No attributes are currently defined for this class.
SUPAPolicyComponentStructure class.
5.4.2. SUPAPolicyComponentStructure Relationships 5.4.2. SUPAPolicyComponentStructure Relationships
SUPAPolicyComponentStructure participates in a single relationship, SUPAPolicyComponentStructure participates in a single relationship,
SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. It
also inherits the SUPAHasPolicyMetadata aggregation
(see section 5.17.2.1.).
5.5. The Abstract Class "SUPAPolicyClause" 5.5. The Abstract Class "SUPAPolicyClause"
This is a mandatory abstract class that separates the This is a mandatory abstract class that separates the
representation of a SUPAPolicy from its implementation. representation of a SUPAPolicy from its implementation.
SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction
is missing in [RFC3060], [RFC3460], [4], and [6]. This class is is missing in [RFC3060], [RFC3460], [4], and [6]. This class is
called PolicyStatement in [5], but the class and relationship called PolicyStatement in [5], but the class and relationship
definitions differ significantly from the corresponding designs definitions differ significantly from the corresponding designs
in this document. in this document.
skipping to change at page 60, line 32 skipping to change at page 64, line 32
dynamically at runtime without affecting other objects. dynamically at runtime without affecting other objects.
This document defines two different types of policy clauses: This document defines two different types of policy clauses:
SUPAEncodedClause (which is generic, and can be used by any SUPAEncodedClause (which is generic, and can be used by any
type of policy), and SUPABooleanClause (which is also generic, type of policy), and SUPABooleanClause (which is also generic,
but is typically used by SUPAECAPolicyRule objects, since it is but is typically used by SUPAECAPolicyRule objects, since it is
used specifically to represent Boolean clauses). used specifically to represent Boolean clauses).
SUPAPolicyClauses are objects in their own right, which SUPAPolicyClauses are objects in their own right, which
facilitates their reuse. SUPAPolicyClauses can aggregate a set facilitates their reuse. SUPAPolicyClauses can aggregate a set
of any of the subclasses of SUPAPolicyComponentDecorator, which of any of the subclasses of SUPAPolicyClauseComponentDecorator; this
was shown in Figure 10. These four subclasses (i.e., SUPAPolicyTerm, was shown in Figures 12 and 13. These five subclasses (i.e.,
SUPAGenericDecoratedComponent, SUPAECAComponent, and SUPACollection) SUPAPolicyTerm, SUPAGenericDecoratedComponent, SUPAECAComponent,
provide four different ways to construct a SUPAPolicyClause: SUPACollection, and SUPAPolicyComponentDecorator) provide several
different ways to construct a SUPAPolicyClause:
1) a SUPAPolicyClause can be made up of a set of three 1) a SUPAPolicyClause can be made up of a set of three
SUPAPolicyTerms, which enables constructing a {variable, SUPAPolicyTerms, which enables constructing an expression
operator, value} expression for building SUPAPolicyClauses consiting of a {variable, operator, value} 3-tuple, for
building SUPAPolicyClauses
2) a SUPAPolicyClause can be made up of one or more 2) a SUPAPolicyClause can be made up of one or more
SUPAEncodedClauses, which enables a SUPAPolicyClause to be SUPAEncodedClauses, which enables a SUPAPolicyClause to be
formed as an encoded object (e.g., to pass YANG or CLI code) formed as an encoded object (e.g., to pass YANG or CLI code)
3) a SUPAPolicyClause can be made up of a set of SUPACollections, 3) a SUPAPolicyClause can be made up of a set of SUPACollections,
which define a Collection (e.g., set, bad, associative arrays) which define a Collection (e.g., set, bad, associative arrays)
of objects that can be assembled into SUPAPolicyClauses of objects that can be assembled into SUPAPolicyClauses after
further processing
4) a SUPAPolicyClause can be made up of one or more 4) a SUPAPolicyClause can be made up of one or more
SUPAECAComponents, which enables a SUPAPolicyClause to be SUPAECAComponents, which enables a SUPAPolicyClause to be
formed using (reusable) Event, Condition, and/or Action formed using (reusable) Event, Condition, and/or Action objects
objects 5) any or all of the above methods can be augmented with more
complex decorated structures using SUPAPolicyComponentDecorator
SUPAPolicyClauses are aggregated by a SUPAPolicyStructure SUPAPolicyClauses are formed by aggregating a set of concrete
object, which enables all types of SUPAPolicies to uniformly be subclasses of the SUPAPolicyClauseComponentDecorator class using the
made up of one or more SUPAPolicyClauses. SUPAPolicyClauseHasDecorator aggregation (see Figure 12). The
resulting SUPAPolicyClause is then aggregated by a concrete
subclass of the SUPAPolicyStructure class, which enables a
SUPAPolicy to be made up of one or more SUPAPolicyClauses.
5.5.1. SUPAPolicyClause Attributes 5.5.1. SUPAPolicyClause Attributes
This section defines the attributes of the SUPAPolicyClause This section defines the attributes of the SUPAPolicyClause
class, which are inherited by all SUPAPolicyClause subclasses. class, which are inherited by all SUPAPolicyClause subclasses.
5.5.1.1. The Attribute "supaPolClauseDeployStatus" 5.5.1.1. The Attribute "supaPolClauseDeployStatus"
This is an optional enumerated, non-negative integer attribute. The This is an optional enumerated, non-negative integer attribute. The
purpose of this attribute is to indicate that this SUPAPolicyClause purpose of this attribute is to indicate that this SUPAPolicyClause
skipping to change at page 61, line 37 skipping to change at page 65, line 44
The values 0 and 1 represent an error state and an initialization The values 0 and 1 represent an error state and an initialization
state, respectively. If the value of this attribute is 0 or 6, then state, respectively. If the value of this attribute is 0 or 6, then
the policy management system SHOULD ignore this SUPAPolicy. the policy management system SHOULD ignore this SUPAPolicy.
Otherwise, the policy management system MAY use this SUPAPolicyClause Otherwise, the policy management system MAY use this SUPAPolicyClause
(once this SUPAPolicyClause is deployed and enabled). However, a (once this SUPAPolicyClause is deployed and enabled). However, a
value of 4 means that this policy is not admininstratively enabled value of 4 means that this policy is not admininstratively enabled
for use and SHOULD NOT be used in OAM&P policies. for use and SHOULD NOT be used in OAM&P policies.
5.5.2. SUPAPolicyClause Relationships 5.5.2. SUPAPolicyClause Relationships
SUPAPolicyClause participates in a single relationship, SUPAPolicyClause participates in two relationships. The first,
SUPAHasPolicyClause, as defined in section 5.3.2.7. Note that SUPAHasPolicyClause, was defined in section 5.3.2.7. The second,
SUPAPolicyClause uses the decorator pattern to "wrap" this object SUPAPolicyClauseHasDecorator, is defined below. Note that
with instances of the (concrete) subclasses of the SUPAPolicyClause uses the SUPAPolicyClauseHasDecorator aggregation
SUPAPolicyComponentDecorator object. to implement the decorator pattern; this enables a SUPAPolicyClause
to be "wrapped" with instances of the (concrete) subclasses of the
SUPAPolicyClauseComponentDecorator object.
5.5.2.1. The Aggregation "SUPAPolicyClauseHasDecorator"
This is a mandatory aggregation, and is part of a decorator
pattern. It is used to enable a concrete instance of a
SUPAPolicyClauseComponentDecorator to dynamically add behavior to a
specific type (of concrete subclass) of a SUPAPolicyClause object.
The semantics of this aggregation are defined by the
SUPAPolicyClauseHasDecoratorDetail association class.
The multiplicity of this aggregation is 0..n - 0..n. This means
that a SUPAPolicyClause does not have to be decorated; however, if
it is, then zero or more concrete subclasses of the
SUPAPolicyClauseComponentDecorator class may be used to decorate
the concrete subclass of SUPAPolicyClause.
5.5.2.2. The Association Class "SUPAPolicyClauseHasDecoratorDetail"
This is a mandatory concrete association class, and defines the
semantics of the SUPAPolicyClauseHasDecorator aggregation. The
purpose of this class is to use the Decorator pattern to determine
which SUPAPolicyClauseComponentDecorator object instances, if any,
are required to augment the functionality of the concrete subclass
of the SUPAPolicyClause that is being used.
Currently, there are two attributes defined for this class, which
are described in the following subsections. Both attributes are
used in this association class to **constrain the relationship**
between the concrete subclass of SUPAPolicyClauseComponentDecorator
that is wrapping the concrete subclass of SUPAPolicyClause. Note
that class attributes of SUPAPolicyClauseComponentDecorator (see
section 5.9.2) only affect that specific subclass.
5.5.2.2.1. The Attribute "supaPolClauseDecConstraintEncoding"
This is a mandatory non-negative enumerated integer that defines
how to interpret each string in the supaPolClauseDecConstraint
class attribute. Values include:
0: error
1: init
2: OCL 2.4
3: OCL 2.x
4: OCL 1.x
5: QVT 1.2 - Relations Language
6: QVT 1.2 - Operational language
7: Alloy
8: ASCII Text
Enumerations 0 and 1 signify an error state and an initialization
state, respectively. Enumerations 2-4 are dedicated to OCL (with
OCL 2.4 being the latest version as of this writing). QVT defines a
set of languages [20] (the two most powerful and useful are defined
by enumerations 5 and 6). Alloy is a language for describing
constraints, and uses a SAT solver to guarantee correctness [21].
Enumeration 8 (ASCII Text) is not recommended (since it is informal,
and hence, not verifiable), but is included for completeness.
5.5.2.2.2. The Attribute "supaPolClauseDecConstraint[0..n]"
This is a mandatory array of string attributes. Each attribute
specifies a constraint to be applied using the encoding defined in
the supaPolCompConstraintEncoding class attribute. This provides
a more rigorous and flexible treatment of constraints than is
possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that
this is a multi-valued property that may have zero or
more attributes.
5.6. The Concrete Class "SUPAEncodedClause" 5.6. The Concrete Class "SUPAEncodedClause"
This is a mandatory concrete class that refines the behavior of a This is a mandatory concrete class that refines the behavior of a
SUPAPolicyClause. SUPAPolicyClause.
This class defines a generalized extension mechanism for This class defines a generalized extension mechanism for
representing SUPAPolicyClauses that have not been modeled representing SUPAPolicyClauses that have not been modeled with
with other SUPAPolicy objects. Rather, the contents of the policy other SUPAPolicy objects. This class encodes the contents of the
clause are directly encoded into the attributes of the policy clause directly into the attributes of the SUPAEncodedClause.
SUPAEncodedClause. Hence, SUPAEncodedClause objects are reusable Hence, SUPAEncodedClause objects are reusable at the object level,
at the object level, whereas SUPABooleanClause clauses are reusable whereas SUPABooleanClause clauses are reusable at the individual
at the individual Boolean expression level. Boolean expression level.
This class uses two of its attributes (supaEncodedClauseContent and This class uses two of its attributes (supaEncodedClauseContent and
supaEncodedClauseEncoding) for defining the content and type of supaEncodedClauseEncoding) for defining the content and type of
encoding used in a given SUPAPolicyClause. The benefit of a encoding used in a given SUPAPolicyClause. The benefit of a
SUPAEncodedClause is that it enables direct encoding of the text of SUPAEncodedClause is that it enables direct encoding of the text of
the SUPAPolicyClause, without having the "overhead" of using other the SUPAPolicyClause, without having the "overhead" of using other
objects. However, note that while this method is efficient, it objects. However, note that while this method is efficient, it
does not reuse other SUPAPolicy objects. Furthermore, its potentially does not reuse other SUPAPolicy objects. Furthermore, its potential
for reuse is reduced, as only SUPAPolicies that can use the exact for reuse is reduced, as only SUPAPolicies that can use the exact
encoding of this clause can reuse this object. encoding of this clause can reuse this object.
5.6.1. SUPAEncodedClause Attributes 5.6.1. SUPAEncodedClause Attributes
This section defines the attributes of the SUPAEncodedClause class. This section defines the attributes of the SUPAEncodedClause class.
Prescriptive and/or descriptive information about the usage of this Prescriptive and/or descriptive information about the usage of this
SUPAEncodedClause may be provided by one or more SUPAPolicyMetadata SUPAEncodedClause may be provided by one or more SUPAPolicyMetadata
objects, which are each attached to the object instance of this objects, which are each attached to the object instance of this
SUPAEncodedClause. SUPAEncodedClause.
skipping to change at page 63, line 36 skipping to change at page 69, line 17
This is an optional Boolean attribute that emulates a Boolean This is an optional Boolean attribute that emulates a Boolean
response of this clause, so that it may be combined with other response of this clause, so that it may be combined with other
subclasses of the SUPAPolicyClause that provide a status as to subclasses of the SUPAPolicyClause that provide a status as to
their correctness and/or evaluation state. This enables this their correctness and/or evaluation state. This enables this
object to be used to construct more complex Boolean clauses. object to be used to construct more complex Boolean clauses.
Note that this attribute does NOT have to be implemented by all Note that this attribute does NOT have to be implemented by all
data model implementations (e.g., [15]). data model implementations (e.g., [15]).
5.6.2. SUPAEncodedClause Relationships 5.6.2. SUPAEncodedClause Relationships
SUPAPolicyClause participates in a single inherited relationship, SUPAPolicyClause participates in two inherited relationships. These
SUPAHasPolicyClause, as defined in section 5.3.2.7. are SUPAHasPolicyClause, as defined in section 5.3.2.7, and
SUPAPolicyClauseHasDecorator, as defined in section 5.7.2.
5.7. The Abstract Class "SUPAPolicyComponentDecorator" 5.7. The Abstract Class "SUPAPolicyClauseComponentDecorator"
This is a mandatory class, and is used to implement the decorator This is a mandatory class, and is used to implement the decorator
pattern. The decorator pattern enables all or part of one or more pattern. The decorator pattern enables all or part of one or more
objects to "wrap" another concrete object. This means that any objects to "wrap" another concrete object. This means that any
any concrete subclass of SUPAPolicyClause is wrapped by any any concrete subclass of SUPAPolicyClause can be wrapped by any
concrete subclass of SUPAPolicyComponentDecorator, as shown in concrete subclass of SUPAPolicyClauseComponentDecorator, as shown in
Figure 19 below. Figure 22 below.
A SUPAHasPolicyClause
+------------------------------+ +----------------+----------------------------+
| | 1..n | ^ |
| SUPAPolicyComponentStructure +--------+ | | |
| | | used to wrap | C | |
+------------------------------+ | concrete | +-------------+----------------------+ |
/ \ | subclasses of | | SUPAPolicyClauseHasDecoratorDetail | |
I | PolicyClause | +-------------+----------------------+ |
I | | |
+---------------+--------------+ / \ | |
I I A / \ |
A I A I \ / 0..1 A |
+----------+---------+ +--------------+-----+---------+ A \ / 0..n A \ / 1..n
| SUPAPolicyClause | | SUPAPolicyComponentDecorator | +--------+-----------+ +---------------------------+--------+
+----------+---------+ +--------------+---------------+ | SUPAPolicyClause | | SUPAPolicyClauseComponentDecorator |
+----------+---------+ +--------------+---------------------+
I I I I
I I I I
/ \ / \ / \ / \
Concrete Subclasses, Concrete Subclasses Concrete Subclasses, Concrete Subclasses
(e.g., SUPAEncodedClause) (e.g., SUPAPolicyEvent) (e.g., SUPAEncodedClause) (e.g., SUPAPolicyEvent)
(object being wrapped) (wrapping object(s)) that are being wrapped that are the wrapping object(s)
Figure 19. The PolicyComponent Decorator Pattern
5.7.1. The Decorator Pattern
Each SUPAPolicyComponentDecorator object HAS_A (i.e., wraps) a
concrete instance of the SUPAPolicyClause object. This means that
the SUPAPolicyComponentDecorator object has an instance variable
that holds a reference to a SUPAPolicyClause object. Since the
SUPAPolicyComponentDecorator object has the same interface as the
SUPAPolicyClause object, the SUPAPolicyComponentDecorator object
(and all of its subclasses) are transparent to clients of the
SUPAPolicyClause object (and its subclasses). This means that
SUPAPolicyComponentDecorator object instances can add attributes
and/or methods to those of the concrete instance of the chosen
subclass of SUPAPolicyClause.
Figure 20 shows how this is done for methods.
- Figure 20a shows the initial object to be wrapped
- Figure 20b shows the SUPAPolicyEvent object wrapping the
SUPAEncodedClause object
- Figure 20c shows SUPAGenericDecoratedComponent object
wrapping the SUPAPolicyEvent object.
+-------------------+
| SUPAEncodedClause |
| eval() |
+-------------------+
(a) Initial Object
===>
+------------------------+
| SUPAPolicyEvent |
| eval() |
| +-------------------+ |
| | SUPAEncodedClause | |
| | eval() | |
| +-------------------+ |
+------------------------+
(b) SUPAPolicyEvent "wraps" SUPAEncodedClause
===>
+--------------------------------+
| SUPAGenericDecoratedComponent |
| eval() |
| +-----------------------+ |
| | SUPAPolicyEvent | |
| | eval() | |
| | +-------------------+ | |
| | | SUPAEncodedClause | | |
| | | eval() | | |
| | +-------------------+ | |
| +-----------------------+ |
+--------------------------------+
(c) SUPAGenericDecoratedComponent "wraps" SUPAPolicyEvent
Figure 20. Conceptual Depiction of eval() Decorated Method Figure 22. SUPAPolicyClauseComponentDecorator
When the eval() method is called in the outermost object The SUPAHasPolicyClause aggregation enables one or more concrete
(SUPAGenericDecoratedComponent), it delegates to the eval() method subclasses of SUPAPolicyClauseComponentDecorator to wrap a concrete
of SUPAPolicyEvent, which in turn delegates to the eval() method subclass of SUPAPolicyClause. Its semantics are defined by the
of SUPAEncodedClause. This method executes and returns the SUPAPolicyClauseHasDecoratorDetail association class.
results to SUPAPolicyEvent, which executes and returns the results
to SUPAGenericDecoratedComponent, which executes and returns the
final result.
5.7.2. SUPAPolicyComponentDecorator Attributes 5.7.1. SUPAPolicyClauseComponentDecorator Attributes
Currently, there are two attributes defined for this class, which Currently, there are two attributes defined for this class, which
are described in the following subsections. Both attributes are are described in the following subsections. Both attributes are
used by subclasses to constrain the behavior of that subclass; used by subclasses to **constrain the behavior of that subclass**;
they do **not** affect the relationship between the concrete they do **not** affect the relationship between the concrete
subclass of SUPAPolicyComponentDecorator that is wrapping the subclass of SUPAPolicyClauseComponentDecorator that is wrapping
concrete subclass of SUPAPolicyClause. the concrete subclass of SUPAPolicyClause.
This is different than the use of similar attributes defined in This is different than the use of similar attributes defined in
the SUPAHasDecoratedPolicyComponentDetail association class (which the SUPAPolicyClauseHasDecoratorDetail association class. The
are used to constrain the relationship between the concrete attributes of SUPAPolicyClauseComponentDecorator are used to
subclass of SUPAPolicyClause and the concrete subclass of the constrain the (concrete subclass of) SUPAPolicyClause that this
SUPAPolicyComponentDecorator object that is wrapping it). SUPAPolicyClauseComponentDecorator is wrapping. In contrast, the
Note that [2] does not define any attributes for this class. attributes of SUPAPolicyClauseHasDecoratorDetail are used to
define which concrete subclasses of SUPAPolicyClause can be wrapped
by which concrete subclasses of SUPAPolicyClauseComponentDecorator.
5.7.2.1. The Attribute "supaPolCompConstraintEncoding" 5.7.1.1. The Attribute "supaPolClauseConstraintEncoding"
This is a mandatory non-negative enumerated integer that defines This is a mandatory non-negative enumerated integer that defines
how to interpret each string in the supaPolCompConstraint class how to interpret each string in the supaPolCompConstraint class
attribute. Values include: attribute. Values include:
0: error 0: error
1: init 1: init
2: OCL 2.4 2: OCL 2.4
3: OCL 2.x 3: OCL 2.x
4: OCL 1.x 4: OCL 1.x
5: QVT 1.2 - Relations Language 5: QVT 1.2 - Relations Language
6: QVT 1.2 - Operational language 6: QVT 1.2 - Operational language
7: Alloy 7: Alloy
8: ASCII Text 8: ASCII Text
Enumerations 1 and 2 signify an error state and an initialization Enumerations 0 and 1 signify an error state and an initialization
state, respectively. Enumeraitons 3-5 are dedicated to OCL (with state, respectively. Enumerations 2-4 are dedicated to OCL (with
OCL 2.4 being the latest version as of this writing). QVT defines a OCL 2.4 being the latest version as of this writing). QVT defines a
set of languages [20] (the two most powerful and useful are defined set of languages [20] (the two most powerful and useful are defined
by enumerations 5 and 6). Alloy is a language for describing by enumerations 5 and 6). Alloy is a language for describing
constraints, and uses a SAT solver to guarantee correctness [21]. constraints, and uses a SAT solver to guarantee correctness [21].
Enumeration 8 (ASCII Text) is not recommended (since it is informal, Enumeration 8 (ASCII Text) is not recommended (since it is informal,
and hence, not verifiable), but is included for completeness. and hence, not verifiable), but is included for completeness.
If this class is instantiated, then this attribute SHOULD also be 5.7.1.2. The Attribute "supaPolClauseConstraint[0..n]"
instantiated, and SHOULD be part of a conformant implementation.
5.7.2.2. The Attribute "supaPolCompConstraint[0..n]"
This is a mandatory array of string attributes. Each attribute This is a mandatory array of string attributes. Each attribute
specifies a constraint to be applied using the encoding defined in specifies a constraint to be applied using the encoding defined in
the supaPolCompConstraintEncoding class attribute. This provides the supaPolCompConstraintEncoding class attribute. This provides
a more rigorous and flexible treatment of constraints than is a more rigorous and flexible treatment of constraints than is
possible in [RFC3460], [4], [5], and [6]. possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that
this is a multi-valued property that may have zero or
Note: [0..n] means that this is a multi-valued property that may more attributes.
have zero or more attributes.
5.7.3. SUPAPolicyComponentDecorator Relationships
One relationship is currently defined for this class, which is
described in the following subsection.
5.7.3.1. The Aggregation "SUPAHasDecoratedPolicyComponent"
This is a mandatory aggregation, and is part of a decorator
pattern. It is used to enable a concrete instance of a
SUPAPolicyComponentDecorator to dynamically add behavior to a
specific type of SUPAPolicyClause object. The semantics of this
aggregation are defined by the
SUPAHasDecoratedPolicyComponentDetail association class.
5.7.3.2. The Association Class
"SUPAHasDecoratedPolicyComponentDetail"
This is a mandatory concrete association class, and defines the
semantics of the SUPAHasDecoratedPolicyComponent aggregation. The
purpose of this class is to use the Decorator pattern to determine
which SUPAPolicyComponentDecorator object instances, if any, are
required to augment the functionality of the concrete subclass of
SUPAPolicyClause that is being used.
Currently, there are two attributes defined for this class, which
are described in the following subsections. Both attributes are
used in this association class to constrain the **relationship**
between the concrete subclass of SUPAPolicyComponentDecorator that
is wrapping the concrete subclass of SUPAPolicyClause. Note that
class attributes of SUPAPolicyComponentDecorator (see section
5.9.2) only affect that specific subclass.
5.7.3.2.1. The Attribute "supaDecoratedConstraintEncoding"
This is a mandatory non-negative enumerated integer that defines
how to interpret each string in the supaDecoratedConstraint class
attribute. Values include:
0: error
1: init
2: OCL 2.4
3: OCL 2.x
4: OCL 1.x
5: QVT 1.2 - Relations Language
6: QVT 1.2 - Operational language
7: Alloy
8: ASCII Text
Enumerations 1 and 2 signify an error state and an initialization
state, respectively. Enumeraitons 3-5 are dedicated to OCL (with
OCL 2.4 being the latest version as of this writing). QVT defines a
set of languages [20] (the two most powerful and useful are defined
by enumerations 5 and 6). Alloy is a language for describing
constraints, and uses a SAT solver to guarantee correctness [21].
Enumeration 8 (ASCII Text) is not recommended (since it is informal,
and hence, not verifiable), but is included for completeness.
If this class is instantiated, then this attribute SHOULD also be
instantiated, and SHOULD be part of a conformant implementation.
5.7.3.2.2. The Attribute "supaDecoratedConstraint[0..n]" 5.7.2. SUPAPolicyClauseComponentDecorator Relationships
This is a mandatory array of string attributes. Its purpose is to This class currently participates in two relationships. The first,
collect a set of constraints to be applied to a decorated object. SUPAPolicyClauseHasDecorator, was defined in Section 5.5.2. The
The interpretation of each constraint in the array is defined in second, SUPAHasDecoratedPolicyComponent, is defined in
the supaDecoratedConstraintsEncoding class attribute. Section 5.14.2.
Note: [0..n] means that this is a multi-valued property that may
have zero or more attributes.
5.7.4. Illustration of Constraints in the Decorator Pattern 5.7.3. Illustration of Constraints in the Decorator Pattern
Figure 21 builds a simple SUPAPolicyClause that has both types Figure 23 builds a simple SUPAPolicyClause that has both types
of relationships, and illustrates how the different constraints of relationships, and illustrates how the different constraints
defined in sections 5.7.2 (class attribute constraints) and section defined in sections 5.7.2 (class attribute constraints) and section
5.7.3 (relationship constraints) can be used. 5.7.3 (relationship constraints) can be used.
A A A A
+------------------+ 0..1 +----------------------------+ +----------------+ 0..1 +----------------------------------+
| | 1..n / \| | | | 1..n / \| |
| SUPAPolicyClause +------+----- A +SUPAPolicyComponentDecorator| |SUPAPolicyClause+------+---- A +SUPAPolicyClauseComponentDecorator|
| | ^ \ /| | | | ^ \ /| |
+---------+--------+ | +-----------+----------------+ +---------+------+ | +-----------+----------------------+
I | I / \ | / \
I | I I | I
C I | C I I | I
+--------+--------+ | +---------+---------+ C I | C I
|SUPAEncodedClause| | | SUPAPolicyEvent | +--------+--------+ | +---------+---------+
+-----------------+ | +-------------------+ |SUPAEncodedClause| | | SUPAPolicyEvent |
| +-----------------+ | +-------------------+
C | |
+-----------------+-------------------+ C |
|SUPAHasDecoratedPolicyComponentDetail| +---------------+------------+
+-------------------------------------+ |SUPAPolicyHasDecoratorDetail|
+----------------------------+
Figure 21. Constraints in the Decorator Pattern Figure 23. Constraints in the Decorator Pattern
Figure 21 says that a SUPAPolicyClause, realized as a Figure 23 says that a SUPAPolicyClause, realized as a
SUPAEncodedClause, is wrapped by a SUPAPolicyEvent object. The SUPAEncodedClause object, is wrapped by a
attributes in the SUPAPolicyComponentDecorator object are used SUPAPolicyClauseComponentDecorator, realized as a SUPAPolicyEvent
to constrain the attributes in the SUPAPolicyEvent object, while object. The attributes in the SUPAPolicyClauseComponentDecorator
the attributes in the SUPAHasDecoratedPolicyComponentDetail object, which are inherited by the SUPAPolicyEvent object, are
object are used to contrain the behavior of the aggregation used to constrain the behavior of the SUPAPolicyEvent object.
(SUPAHasDecoratedPolicyComponent). For example, the attributes in
the SUPAPolicyComponentDecorator object could restrict the data Put another way, the SUPAPolicyClauseHasDecorator aggregation
type and range of the components in the SUPAPolicyEvent, while enables a concrete subclass of SUPAPolicyClause to be decorated by
the attributes in the SUPAHasDecoratedPolicyComponentDetail object concrete subclasses of SUPAPolicyClauseComponentDecorator. The
could restrict which SUPAPolicyEvent objects are allowed to be decorator pattern is implemente by the
used with which SUPAEncodedClauses. SUPAHasDecoratedPolicyComponent aggregation. Hence, attributes in
the SUPAHasDecoratedPolicyComponentDetail association class are used
to contrain the behavior of the decorator (e.g., restricting which
concrete subclasses of the SUPAPolicyComponentDecorator can be used
as decorators). For example, the attributes in the
SUPAPolicyClauseComponentDecorator class, when instantiated in an
instance of a concrete subclass, could restrict which
SUPAPolicyEvent objects are allowed to be used with which
SUPAEncodedClause objects.
5.8. The Abstract Class "SUPAPolicyTerm" 5.8. The Abstract Class "SUPAPolicyTerm"
This is a mandatory abstract class that is the parent of This is a mandatory abstract class that is the parent of
SUPAPolicy objects that can be used to define a standard way to SUPAPolicy objects that can be used to define a standard way to
test or set the value of a variable. It does this by defining a test or set the value of a variable. It does this by defining a
3-tuple, in the form {variable, operator, value}, where each 3-tuple, in the form {variable, operator, value}, where each
element of the 3-tuple is defined by a concrete subclass of the element of the 3-tuple is defined by a concrete subclass of the
appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator, appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator,
and SUPAPolicyValue classes, respectively). For example, a and SUPAPolicyValue classes, respectively). For example, a
generic test or set of the value of a variable is expressed as: generic test or set of the value of a variable is expressed as:
{variable, operator, value}. {variable, operator, value}.
For event and condition clauses, this is typically as written above For event and condition clauses, this is typically as written above
(e.g., does variable = value); for action clauses, it is typically (e.g., does variable = value); for action clauses, it is typically
written as <operator> <variable> <value> (e.g., SET var to 1). A written as <operator> <variable> <value> (e.g., SET var to 1). A
class diagram is shown in Figure 22. class diagram is shown in Figure 24.
A A
+----------------+ +----------------+
| SUPAPolicyTerm | | SUPAPolicyTerm |
+--------+-------+ +--------+-------+
/ \ / \
I I
I I
I I
+-----------------+---+--------------------+ +-----------------+---+--------------------+
I I I I I I
I I I I I I
C I C I C I C I C I C I
+--------+---------+ +--------+---------+ +-------+-------+ +--------+---------+ +--------+---------+ +-------+-------+
|SUPAPolicyVariable| |SUPAPolicyOperator| |SUPAPolicyValue| |SUPAPolicyVariable| |SUPAPolicyOperator| |SUPAPolicyValue|
+------------------+ +------------------+ +---------------+ +------------------+ +------------------+ +---------------+
Figure 22. SUPAPolicyTerm Class Hierarchy Figure 24. SUPAPolicyTerm Class Hierarchy
Note that generic test and set expressions do not have to only use Note that generic test and set expressions do not have to only use
objects that are subclasses of SUPAPolicyTerm. For example, the objects that are subclasses of SUPAPolicyTerm. For example, the
polVendorDecoratedContent attribute of the supaGenericDecoratedCompContent attribute of the
SUPAGenericDecoratedComponent could be used as the variable (or the SUPAGenericDecoratedComponent could be used as the variable (or the
value) term of a get or set expression. value) term of a get or set expression that is in the above form.
Hence, the utility of the subclasses of SUPAPolicyTerm is in the Hence, the utility of the subclasses of SUPAPolicyTerm is in the
ability of its subclasses to define a generic framework for ability of its subclasses to define a generic framework for
implementing get and set expressions. This is in contrast to implementing get and set expressions. This is in contrast to
previous designs (e.g., [RFC3460] and [6]), which depended on previous designs (e.g., [RFC3460] and [6]), which depended on
defining a broad set of subclasses of PolicyVariable and defining a broad set of subclasses of PolicyVariable and
PolicyValue. (Note that [4] does not have this generic capability). PolicyValue. (Note that [4] does not have this generic capability).
5.8.1. SUPAPolicyTerm Attributes 5.8.1. SUPAPolicyTerm Attributes
Currently, SUPAPolicyTerm defines a single attribute, as described Currently, SUPAPolicyTerm defines a single attribute, as described
in the following subsection. Constraints on the subclasses of in the following subsection. Constraints on the subclasses of
SUPAPolicyTerm can be applied in two different ways: SUPAPolicyTerm can be applied in two different ways:
1. use SUPAPolicyComponentDecorator attributes to constrain 1. use SUPAPolicyComponentDecorator attributes to constrain
just that individual subclass, and/or just that individual subclass, and/or
2. use SUPAHasDecoratedPolicyComponentDetail association class 2. use SUPAHasDecoratedPolicyComponentDetail association class
attributes to constrain the relationship between the concrete attributes to constrain the relationship between the concrete
subclass of SUPAPolicyClause and the concrete subclass of subclass of SUPAPolicyClause and the concrete subclass of
the SUPAPolicyTerm class the SUPAPolicyTerm class; this determines which concrete
subclasses of SUPAPolicyTerm can be used to construct this
particular SUPAPolicyClause.
5.8.1.1. The Attribute "supaPolTermIsNegated" 5.8.1.1. The Attribute "supaPolTermIsNegated"
This is a mandatory Boolean attribute. If the value of this This is a mandatory Boolean attribute. If the value of this
attribute is true, then this particular SUPAPolicyTerm subclass attribute is true, then this particular SUPAPolicyTerm subclass
(which represents a term) is negated; otherwise, it is not. (which represents a term) is negated; otherwise, it is not.
5.8.2. SUPAPolicyTerm Relationships 5.8.2. SUPAPolicyTerm Relationships
Currently, no dedicated relationships are defined for the Currently, no dedicated relationships are defined for the
SUPAPolicyTerm class (as there are in [RFC3460] and [6]) that SUPAPolicyTerm class (as there are in [RFC3460] and [6]) that
aggregate policy variable and policy value objects into a policy aggregate policy variable and policy value objects into a policy
rule). This is: rule). This is:
1) to enable the subclasses of SUPAPolicyTerm to be used by 1) to enable the subclasses of SUPAPolicyTerm to be used by
other SUPAPolicyComponentDecorator objects, and other SUPAPolicyComponentDecorator objects, and
2) because the decorator pattern replaces how such relationships 2) because the decorator pattern replaces how such relationships
were used in [RFC3460] and [6]. were used in [RFC3460] and [6].
SUPAPolicyTerm, and its subclasses, inherit the SUPAPolicyTerm, and its subclasses, inherit the
SUPAHasDecoratedPolicyComponent aggregation, which was defined in SUPAPolicyClauseHasDecorator aggregation, which was defined in
section 5.7.3. Section 5.5.2, as well as the SUPAHasDecoratedPolicyComponent
aggregation, which was defined in section 5.7.3.
5.9. The Concrete Class "SUPAPolicyVariable" 5.9. The Concrete Class "SUPAPolicyVariable"
This is a mandatory concrete class that defines information that This is a mandatory concrete class that defines information that
forms a part of a SUPAPolicyClause. It specifies a concept or forms a part of a SUPAPolicyClause. It specifies a concept or
attribute that represents a variable, which should be compared to attribute that represents a variable, which should be compared to
a value, as specifed in this SUPAPolicyClause. If it is used in a value, as specifed in this SUPAPolicyClause. If it is used in
a SUPAECAPolicyRule, then its value MAY be able to be changed at a SUPAECAPolicyRule, then its value MAY be able to be changed at
any time, including run-time, via use of the decorator pattern. any time, including run-time, via use of the decorator pattern.
This is not possible in previous designs ([RFC3460, [4], and [6]). This is not possible in previous designs ([RFC3460, [4], and [6]).
The value of a SUPAPolicyVariable is typically compared to the The value of a SUPAPolicyVariable is typically compared to the
value of a SUPAPolicyValue using the type of operator defined in value of a SUPAPolicyValue using the type of operator defined in
a SUPAPolicyOperator. However, other objects may be used instead a SUPAPolicyOperator. However, other objects may be used instead
of a SUPAPolicyValue object, and other operators may be defined of a SUPAPolicyValue object, and other operators may be defined
in addition to those defined in the SUPAPolicyOperator class. in addition to those defined in the SUPAPolicyOperator class.
SUPAPolicyVariables are used to abstract the representation of a SUPAPolicyVariables are used to abstract the representation of a
SUPAPolicyRule from its implementation. Some SUPAPolicyVariables SUPAPolicyClause from its implementation. Some SUPAPolicyVariables
are restricted in the values and/or the data type that they may are restricted in the values and/or the data type that they may
be assigned. For example, port numbers cannot be negative, and be assigned. For example, port numbers cannot be negative, and
they cannot be floating-point numbers. These and other constraints they cannot be floating-point numbers. These and other constraints
may be defined in two different ways: may be defined in two different ways:
1. use SUPAPolicyComponentDecorator attributes to constrain 1. use SUPAPolicyClauseComponentDecorator attributes to constrain
just that individual subclass, and/or just that individual object, and/or
2. use SUPAHasDecoratedPolicyComponentDetail association class 2. use the SUPAPolicyClauseHasDecoratorDetail association class
attributes to constrain the relationship between the concrete attributes to constrain the relationship between the concrete
subclass of SUPAPolicyClause and the concrete subclass of subclass of SUPAPolicyClause and the concrete subclass of
the SUPAPolicyVariable class the SUPAPolicyVariable class
Please refer to the examples in section 7, which show how to Please refer to the examples in section 7, which show how to
restrict the value, data type, range, and other semantics of the restrict the value, data type, range, and other semantics of the
SUPAPolicyVariable when used in a SUPAPolicyClause. SUPAPolicyVariable when used in a SUPAPolicyClause.
5.9.1. Problems with the RFC3460 Version of PolicyValue 5.9.1. Problems with the RFC3460 Version of PolicyValue
skipping to change at page 71, line 54 skipping to change at page 75, line 22
section 5.7.3. section 5.7.3.
5.10. The Concrete Class "SUPAPolicyOperator" 5.10. The Concrete Class "SUPAPolicyOperator"
This is a mandatory concrete class for modeling different types of This is a mandatory concrete class for modeling different types of
operators that are used in a SUPAPolicyClause. operators that are used in a SUPAPolicyClause.
The restriction of the type of operator used in a SUPAPolicyClause The restriction of the type of operator used in a SUPAPolicyClause
restricts the semantics that can be expressed in that restricts the semantics that can be expressed in that
SUPAPolicyClause. It is typically used with SUPAPolicyVariables SUPAPolicyClause. It is typically used with SUPAPolicyVariables
and SUPAPolicyValue to form a SUPAPolicyClause. and SUPAPolicyValues to form a SUPAPolicyClause.
5.10.1. Problems with the RFC3460 Version 5.10.1. Problems with the RFC3460 Version
Please see Appendix A for a detailed comparison. Please see Appendix A for a detailed comparison.
5.10.2. SUPAPolicyOperator Attributes 5.10.2. SUPAPolicyOperator Attributes
Currently, SUPAPolicyOperator defines a single generic attribute, Currently, SUPAPolicyOperator defines a single generic attribute,
as described below. as described below.
skipping to change at page 72, line 33 skipping to change at page 75, line 52
3: Greater than or equal to 3: Greater than or equal to
4: Less than 4: Less than
5: Less than or equal to 5: Less than or equal to
6: Equal to 6: Equal to
7: Not equal to 7: Not equal to
8: IN 8: IN
9: NOT IN 9: NOT IN
10: SET 10: SET
11: CLEAR (0 for integers, "" for strings, FALSE for Booleans) 11: CLEAR (0 for integers, "" for strings, FALSE for Booleans)
12: BETWEEN (inclusive) 12: BETWEEN (inclusive)
13: regular expression, PERL-based
14: regular expression, POSIX-based (BRE, basic)
15: regular expression, POSIX-based (ERE, extended)
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. Their purpose is to support dynamically building a respectively. Their purpose is to support dynamically building a
SUPAPolicyClause by enabling the application to set the value of SUPAPolicyClause by enabling the application to set the value of
this attribute to a standard value. this attribute to a standard value.
This list has been influenced by the work in the I2NSF WG.
Specifically, references [22] and [23] categorize selectors as
exact-match, range-based, regular expressions, and custom match. In
this categorization, the values in the above enumeration are mapped
as follows:
o "Exact-match" is used to check for equality. The result is an
unstructured unordered set. This includes values 6 and 7.
o "Range-based" are **ordered** sets, where ranges that map to
integers are used. This includes values 2-5, 8, 9, and 12.
o "Regular expressions", which include the use of special
characters that collectively define a search pattern. Two
different syntaxes are specified; they are documented in [24]
(for value 14) and [25]. This maps to values 13-15.
Note that POSIX-based simple regular expressions (SRE) are
**deprecated** by POSIX-based basic regular expressions (BRE).
Additional operators may be defined in future work. For example, Additional operators may be defined in future work. For example,
if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from
include structured objects, then "deep" versions of operators include structured objects, then "deep" versions of operators
1-6 could also be defined. In this case, values 1-6 will be 1-6 could also be defined. In this case, values 1-6 will be
edited to explicitly indicate that they perform "shallow" edited to explicitly indicate that they perform "shallow"
comparison operations. comparison operations.
5.10.3. SUPAPolicyOperator Relationships 5.10.3. SUPAPolicyOperator Relationships
Currently, no relationships are defined for the SUPAPolicyOperator Currently, no relationships are defined for the SUPAPolicyOperator
skipping to change at page 73, line 13 skipping to change at page 76, line 54
semantics of the SUPAPolicyOperator when used in a SUPAPolicyClause. semantics of the SUPAPolicyOperator when used in a SUPAPolicyClause.
5.11. The Concrete Class "SUPAPolicyValue" 5.11. The Concrete Class "SUPAPolicyValue"
The SUPAPolicyValue class is a mandatory concrete class for The SUPAPolicyValue class is a mandatory concrete class for
modeling different types of values and constants that occur in a modeling different types of values and constants that occur in a
SUPAPolicyClause. SUPAPolicyClause.
SUPAPolicyValues are used to abstract the representation of a SUPAPolicyValues are used to abstract the representation of a
SUPAPolicyRule from its implementation. Therefore, the design of SUPAPolicyRule from its implementation. Therefore, the design of
SUPAPolicyValues depends on two important factors. First, just as SUPAPolicyValues depends on two important factors.
with SUPAPolicyVariables (see Section 5.11), some types of
SUPAPolicyValues are restricted in the values and/or the data First, just as with SUPAPolicyVariables (see Section 5.9), some
type that they may be assigned. Second, there is a high likelihood types of SUPAPolicyValues are restricted in the values and/or the
that specific applications will need to use their own variables data type that they may be assigned. Second, there is a high
that have specific meaning to a particular application. likelihood that specific applications will need to use their own
variables that have specific meaning to a particular application.
In general, there are two ways to apply constraints to an object In general, there are two ways to apply constraints to an object
instance of a SUPAPolicyValue: instance of a SUPAPolicyValue:
1. use SUPAPolicyComponentDecorator attributes to constrain 1. use SUPAPolicyClauseComponentDecorator attributes to constrain
just that individual subclass, and/or just that individual object, and/or
2. use SUPAHasDecoratedPolicyComponentDetail association class 2. use the SUPAPolicyClauseHasDecoratorDetail association class
attributes to constrain the relationship between the concrete attributes to constrain the relationship between the concrete
subclass of SUPAPolicyClause and the concrete subclass of subclass of SUPAPolicyClause and the concrete subclass of
the SUPAPolicyValue class the SUPAPolicyVariable class
The value of a SUPAPolicyValue is typically compared to the value The value of a SUPAPolicyValue is typically compared to the value
of a SUPAPolicyVariable using the type of operator defined in of a SUPAPolicyVariable using the type of operator defined in
a SUPAPolicyOperator. However, other objects may be used instead a SUPAPolicyOperator. However, other objects may be used instead
of a SUPAPolicyVariable object, and other operators may be defined of a SUPAPolicyVariable object, and other operators may be defined
in addition to those defined in the SUPAPolicyOperator class. in addition to those defined in the SUPAPolicyOperator class.
Please refer to the examples in section 7, which show how to
restrict the value, data type, range, and other semantics of the
SUPAPolicyVariable when used in a SUPAPolicyClause.
5.11.1. Problems with the RFC3460 Version of PolicyValue 5.11.1. Problems with the RFC3460 Version of PolicyValue
Please see Appendix A for a detailed comparison. Please see Appendix A for a detailed comparison.
5.11.2. SUPAPolicyValue Attributes 5.11.2. SUPAPolicyValue Attributes
Currently, SUPAPolicyValue defines two generic attributes, as Currently, SUPAPolicyValue defines two generic attributes, as
described below. described below.
5.11.2.1. The Attribute "supaPolValContent[0..n]" 5.11.2.1. The Attribute "supaPolValContent[0..n]"
This is a mandatory attribute that defines an array of strings. This is a mandatory attribute that defines an array of strings.
The array contains the value(s) of this SUPAPolicyValue object The array contains the value(s) of this SUPAPolicyValue object
instance. Its data type is defined by the supaPolValEncoding instance. Its data type is defined by the supaPolValEncoding
class attribute. class attribute. Note: [0..n] means that this is a multi-valued
Note: [0..n] means that this is a multi-valued property that has property that has zero or more attributes.
zero or more attributes.
5.11.2.2. The Attribute "supaPolValEncoding" 5.11.2.2. The Attribute "supaPolValEncoding"
This is a mandatory string attribute that contains the data type This is a mandatory string attribute that contains the data type
of the SUPAPolicyValue object instance. Its value is defined by of the SUPAPolicyValue object instance. Its value is defined by
the supaPolValContent class attribute. Values include: the supaPolValContent class attribute. Values include:
0: error 0: error
1: init 1: init
2: String 2: String
skipping to change at page 75, line 10 skipping to change at page 79, line 5
This class should not be confused with the SUPAEncodedClause class. This class should not be confused with the SUPAEncodedClause class.
The SUPAGenericDecoratedComponent class represents a single, atomic The SUPAGenericDecoratedComponent class represents a single, atomic
object that defines a **portion** of a SUPAPolicyClause, whereas a object that defines a **portion** of a SUPAPolicyClause, whereas a
SUPAEncodedClause represents an **entire** SUPAPolicyClause. SUPAEncodedClause represents an **entire** SUPAPolicyClause.
5.12.1. SUPAGenericDecoratedComponent Attributes 5.12.1. SUPAGenericDecoratedComponent Attributes
Currently, SUPAGenericDecoratedComponent defines two generic Currently, SUPAGenericDecoratedComponent defines two generic
attributes, as described below. attributes, as described below.
5.12.1.1. The Attribute "supaVendorDecoratedCompContent[0..n]" 5.12.1.1. The Attribute "supaGenericDecoratedCompContent[0..n]"
This is a mandatory attribute that defines an array of strings. This is a mandatory attribute that defines an array of strings.
This array contains the value(s) of the This array contains the value(s) of the
SUPAGenericDecoratedComponent object instance. Its data type is SUPAGenericDecoratedComponent object instance that are used to
defined by the supaVendorDecoratedEncoding class attribute. construct a portion of a SUPAPolicyClause. Its data type is
defined by the supaGenericDecoratedCompEncoding class attribute.
Note: [0..n] means that this is a multi-valued property that has Note: [0..n] means that this is a multi-valued property that has
zero or more attributes. zero or more attributes.
5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 5.12.1.2. The Attribute "supaGenericDecoratedCompEncoding"
This is a mandatory integer attribute that defines the format of This is a mandatory integer attribute that defines the format of
the supaVendorDecoratedContent class attribute. Values include: the supaGenericDecoratedCompContent class attribute. Values include:
0: undefined 0: error
1: String 1: init
2: Integer 2: String
3: Boolean 3: Integer
4: Floating Point 4: Boolean
5: DateTime 5: Floating Point
6: GUID 6: DateTime
7: UUID 7: GUID
8: URI 8: UUID
9: FQDN 9: URI
10: FQPN 10: DN
11: NULL 11: FQDN
12: FQPN
13: NULL
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. A string is a sequence of zero or more characters. An respectively. A string is a sequence of zero or more characters. An
Integer is a whole number (e.g., it has no fractional part). A Integer is a whole number, and has no fractional part. A Boolean may
Boolean represents the values TRUE and FALSE. A floating point take the values TRUE and FALSE. A floating point number may contain
number may contain fractional values, as well as an exponent. A fractional values, as well as an exponent. A DateTime represents a
DateTime represents a value that has a date and/or a time component value that has a date and/or a time component (as in the Java or
(as in the Java or Python libraries). A NULL explicitly models the Python libraries). A NULL explicitly models the lack of a value.
lack of a value.
5.12.2. SUPAGenericDecoratedComponent Relationships 5.12.2. SUPAGenericDecoratedComponent Relationships
Currently, no relationships are defiend for the Currently, no relationships are defiend for the
SUPAGenericDecoratedComponent class (note that the decorator SUPAGenericDecoratedComponent class (note that the decorator
pattern obviates the need for relationships such as those in [6]). pattern obviates the need for relationships such as those in [6]).
SUPAGenericDecoratedComponent participates in a single relationship, SUPAGenericDecoratedComponent participates in a single relationship,
SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3.
** This class is under discussion - please comment as to its utility **
5.13. The Concrete Class "SUPAPolicyCollection" 5.13. The Concrete Class "SUPAPolicyCollection"
A SUPAPolicyCollection is an optional concrete class that enables A SUPAPolicyCollection is an optional concrete class that enables
a collection (e.g., set, bag, or other, more complex, collections a collection (e.g., set, bag, or other, more complex, collections
of elements) of **arbitrary objects** to be defined and used as of elements) of **arbitrary objects** to be defined and used as
part of a SUPAPolicyClause. This class was derived from [2], but part of a SUPAPolicyClause. This class was derived from [2], but
is not present in [RFC3460], [4], [5], or [6]. is not present in [RFC3460], [4], [5], or [6].
5.13.1. Motivation 5.13.1. Motivation
One of the problems with ECA policy rules is when a set of events One of the problems with ECA policy rules is when an enumeration
or conditions needs to be tested. For example, if a set of events occurs in the event and/or condition clauses. For example, if a
is received, the policy system may need to wait for patterns of set of events is received, the policy system may need to wait for
events to emerge (e.g., any number of Events of type A, followed patterns of events to emerge (e.g., any number of Events of type A,
by either one event of type B or two events of type Event C). followed by either one event of type B or two events of type
Similarly, for conditions, testing the value of a set of attributes Event C). Similarly, for conditions, testing the value of a set of
may need to be performed. Both of these represent behavior attributes may need to be performed. Both of these represent
similar to a set of if-then-else statements or a switch statement. behavior similar to a set of if-then-else statements or a switch
statement in imperative programming languages.
It is typically not desirable for the policy system to represent It is typically not desirable for the policy system to represent
each choice in such clauses as its own policy clause (i.e., a each choice in such clauses as its own policy clause (i.e., a
3-tuple), as this creates object explosion and poor performance. 3-tuple), as this creates object explosion and poor performance.
Furthermore, in these cases, it is often required to have a set of Furthermore, in these cases, it is often required to have a set of
complex logic to be executed, where the logic varies according to complex logic to be executed, where the logic varies according to
the particular event or condition that was selected. It is much the particular event or condition that was selected. It is much
too complex to represent this using separate objects, especially too complex to represent this using separate objects, especially
when the logic is application- and/or vendor-specific. However, when the logic is application- and/or vendor-specific. However,
recall that one of the goals of this document was to facilitate recall that one of the goals of this document was to facilitate
skipping to change at page 77, line 13 skipping to change at page 81, line 13
SUPAPolicyCollection in a Boolean clause. SUPAPolicyCollection in a Boolean clause.
5.13.3. SUPAPolicyCollection Attributes 5.13.3. SUPAPolicyCollection Attributes
Currently, SUPAGenericDecoratedComponent defines five attributes, Currently, SUPAGenericDecoratedComponent defines five attributes,
as described below. as described below.
5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]"
This is an optional attribute that defines an array of strings. This is an optional attribute that defines an array of strings.
Each string in the array identifies a domain-suitable identifier of Each string in the array defines a domain-suitable identifier of
an object that is collected by this SUPAPolicyCollection instance. an object that is collected by this SUPAPolicyCollection instance.
Note: [0..n] means that this is a multi-valued property that has Note: [0..n] means that this is a multi-valued property that has
zero or more attributes. zero or more attributes.
5.13.3.2. The Attribute "supaPolCollectionEncoding" 5.13.3.2. The Attribute "supaPolCollectionEncoding"
This is an optional non-negative enumerated integer that defines This is a mandatory non-negative enumerated integer that defines
the data type of the content of this collection instance. Values the format of the identifier of all objects in this collection
include: instance. Values include:
0: error 0: error (i.e., an error state)
1: init 1: init (i.e., an initialization state)
2: by regex (regular expression) 2: primary_key
3: by URI 3: foreign_key
4: GUID
5: UUID
6: URI
7: FQDN
8: FQPN
9: string_instance_id
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. If the value of this attribute is 2, then each of the respectively. Values 2-8 define the content as a reference.
strings in the supaPolCollectionContent attribute represent a regex The value 9 defines the canonical representation, in ASCII, of
that contains all or part of a string to match the class name of the an instance ID of this object.
object that is to be collected by this instance of a
SUPAPolicyCollection class. If the value of this attribute is 3,
then each of the strings in the supaPolCollectionContent attribute
represent a URI.
5.13.3.3. The Attribute "supaPolCollectionFunction" 5.13.3.3. The Attribute "supaPolCollectionFunction"
This is an optional non-negative enumerated integer that defines This is an optional non-negative enumerated integer that defines
the function of this collection instance. Values include: the function of this collection instance. Values include:
0: error 0: error
1: init 1: init
2: event collection 2: event collection
3: condition collection 3: condition collection
4: action collection 4: action collection
5: logic collection 5: processing logic collection
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. Values 2-4 define a collection of objects that are to respectively. Values 2-4 define a collection of objects that are to
be used to populate the event, condition, or action clauses, be used to populate the event, condition, or action clauses,
respectively, of a SUPAECAPolicyRule. A value of 4 indicates that respectively, of a SUPAECAPolicyRule. A value of 5 indicates that
this collection contains objects that define logic for processing this collection contains objects that define logic for processing
a SUPAPolicy. a SUPAPolicy.
5.13.3.4. The Attribute "supaPolCollectionIsOrdered" 5.13.3.4. The Attribute "supaPolCollectionIsOrdered"
This is an optional Boolean attribute. If the value of this This is an optional Boolean attribute. If the value of this
attribute is TRUE, then all elements in this instance of this attribute is TRUE, then all elements in this instance of this
SUPAPolicyCollection are ordered. SUPAPolicyCollection are ordered.
5.13.3.5. The Attribute "supaPolCollectionType" 5.13.3.5. The Attribute "supaPolCollectionType"
skipping to change at page 79, line 23 skipping to change at page 83, line 28
An example of a null dictionary is simply {}. An example of a null dictionary is simply {}.
5.13.4. SUPAPolicyCollection Relationships 5.13.4. SUPAPolicyCollection Relationships
Currently, no relationships are defined for the Currently, no relationships are defined for the
SUPAGenericDecoratedComponent class (note that the decorator SUPAGenericDecoratedComponent class (note that the decorator
pattern obviates the need for relationships such as those in [6]). pattern obviates the need for relationships such as those in [6]).
SUPAPolicyCollection participates in a single relationship, SUPAPolicyCollection participates in a single relationship,
SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3.
5.14. The Concrete Class "SUPAPolicySource" 5.14. The Abstract Class "SUPAPolicyComponentDecorator"
This is an optional class, and represents how the decorator pattern
can be applied to objects that decorate another object. This is
shown in Figure 25 below.
A
+--------------+---------------------+
| |/
| SUPAPolicyClauseComponentDecorator +------------+
| |\ |
+----------+-------------------------+ 0..n |
|
SUPAHasDecoratedPolicyComponent |
+---------------------------------+
^ |
| |
C | |
+---------------+---------------------+ |
|SUPAHasDecoratedPolicyComponentDetail| / \
+---------------+---------------------+ A
A \ / 0..1
+---------------+--------------+
| SUPAPolicyComponentDecorator |
+------------------------------+
Figure 25. Decorating Objects that Decorate Another Object
Figure 25 realizes a recursive decorator pattern, in that any
concrete subclass of SUPAPolicyClauseComponentDecorator can be
decorated by any concrete subclass of SUPAPolicyComponentDecorator.
The SUPAHasPolicyClause aggregation enables one or more concrete
subclasses of SUPAPolicyClauseComponentDecorator to wrap a concrete
subclass of SUPAPolicyClause. Its semantics are defined by the
SUPAPolicyClauseHasDecoratorDetail association class.
5.14.1. SUPAPolicyComponentDecorator Attributes
Currently, there are two attributes defined for this class, which
are described in the following subsections. Both attributes are
used by subclasses to **constrain the behavior of that subclass**;
they do **not** affect the relationship between the concrete
subclass of SUPAPolicyComponentDecorator that is wrapping
the concrete subclass of SUPAPolicyClauseComponentDecorator.
This is different than the use of similar attributes defined in
the SUPAHasDecoratedPolicyComponentDetail association class. The
attributes of SUPAPolicyComponentDecorator are used to constrain
the (concrete subclass of) the SUPAPolicyClauseComponentDecorator
that is being wrapped. In contrast, the attributes of
SUPAHasDecoratedPolicyComponentDetail are used to define which
concrete subclasses of SUPAPolicyClauseComponentDecorator can be
wrapped by which concrete subclasses of the
SUPAPolicyComponentDecorator class.
5.14.1.1. The Attribute "supaPolCompConstraintEncoding"
This is a mandatory non-negative enumerated integer that defines
how to interpret each string in the supaPolCompConstraint class
attribute. Values include:
0: error
1: init
2: OCL 2.4
3: OCL 2.x
4: OCL 1.x
5: QVT 1.2 - Relations Language
6: QVT 1.2 - Operational language
7: Alloy
8: ASCII Text
Enumerations 0 and 1 signify an error state and an initialization
state, respectively. Enumerations 2-4 are dedicated to OCL (with
OCL 2.4 being the latest version as of this writing). QVT defines a
set of languages [20] (the two most powerful and useful are defined
by enumerations 5 and 6). Alloy is a language for describing
constraints, and uses a SAT solver to guarantee correctness [21].
Enumeration 8 (ASCII Text) is not recommended (since it is informal,
and hence, not verifiable), but is included for completeness.
5.14.1.2. The Attribute "supaPolCompConstraint[0..n]"
This is a mandatory array of string attributes. Each attribute
specifies a constraint to be applied using the encoding defined in
the supaPolCompConstraintEncoding class attribute. This provides
a more rigorous and flexible treatment of constraints than is
possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that
this is a multi-valued property that may have zero or
more attributes.
5.14.2. SUPAPolicyComponentDecorator Relationships
A single relationship is currently defined for the
SUPAPolicyComponentDecorator, which is described below.
5.14.2.1 The Aggregation "SUPAHasDecoratedPolicyComponent"
This is a mandatory aggregation, and is part of a recursive
decorator pattern. It is used to enable a concrete instance of a
SUPAPolicyComponentDecorator to dynamically add behavior to a
specific type (of concrete subclass) of a
SUPAPolicyClauseComponentDecorator object. The semantics of this
aggregation are defined by the SUPAHasDecoratedPolicyComponentDetail
association class.
5.14.2.2. The Association Class
"SUPAHasDecoratedPolicyComponentDetail"
This is a mandatory concrete association class, and defines the
semantics of the SUPAHasDecoratedPolicyComponent aggregation. The
purpose of this class is to use the Decorator pattern to determine
which concrete subclasses of the SUPAPolicyComponentDecorator class,
if any, are required to augment the functionality of the concrete
subclass of SUPAPolicyClauseComponentDecorator that is being used.
Currently, there are two attributes defined for this class, which
are described in the following subsections. Both attributes are
used in this association class to constrain the **relationship**
between the concrete subclass of SUPAPolicyComponentDecorator that
is wrapping the concrete subclass of the
SUPAPolicyClauseComponentDecorator class.
5.14.2.1.1. The Attribute "supaPolCompConstraintEncoding"
This is a mandatory non-negative enumerated integer that defines
how to interpret each string in the supaDecoratedConstraint class
attribute. Values include:
0: error
1: init
2: OCL 2.4
3: OCL 2.x
4: OCL 1.x
5: QVT 1.2 - Relations Language
6: QVT 1.2 - Operational language
7: Alloy
8: ASCII Text
Enumerations 0 and 1 signify an error state and an initialization
state, respectively. Enumerations 2-4 are dedicated to OCL (with
OCL 2.4 being the latest version as of this writing). QVT defines a
set of languages [20] (the two most powerful and useful are defined
by enumerations 5 and 6). Alloy is a language for describing
constraints, and uses a SAT solver to guarantee correctness [21].
Enumeration 8 (ASCII Text) is not recommended (since it is informal,
and hence, not verifiable), but is included for completeness.
If this class is instantiated, then this attribute SHOULD also be
instantiated, and SHOULD be part of a conformant implementation.
5.14.2.1.2. The Attribute "supaPolCompConstraint[0..n]"
This is a mandatory array of string attributes. Its purpose is to
collect a set of constraints to be applied to a decorated object.
The interpretation of each constraint in the array is defined in
the supaDecoratedConstraintsEncoding class attribute.
Note: [0..n] means that this is a multi-valued property that may
have zero or more attributes.
5.15. The Concrete Class "SUPAPolicySource"
This is an optional class that defines a set of managed entities This is an optional class that defines a set of managed entities
that authored, or are otherwise responsible for, this that authored, or are otherwise responsible for, this
SUPAPolicyRule. Note that a SUPAPolicySource does NOT SUPAPolicyRule. Note that a SUPAPolicySource does NOT
evaluate or execute SUPAPolicies. Its primary use is for evaluate or execute SUPAPolicies. Its primary use is for
auditability and the implementation of deontic and/or alethic logic. auditability and the implementation of deontic and/or alethic logic.
A class diagram is shown in Figure 12. A class diagram is shown in Figure 15.
A SUPAPolicySource SHOULD be mapped to a role or set of roles A SUPAPolicySource SHOULD be mapped to a role or set of roles
(e.g., using the role-object pattern [11]). This enables (e.g., using the role-object pattern [11]). This enables
role-based access control to be used to restrict which entities role-based access control to be used to restrict which entities
can author a given policy. Note that Role is a type of can author a given policy. Note that Role is a type of
SUPAPolicyMetadata. SUPAPolicyMetadata.
5.14.1. SUPAPolicySource Attributes 5.15.1. SUPAPolicySource Attributes
Currently, no attributes are defined for this class. Currently, no attributes are defined for this class.
5.14.2. SUPAPolicySource Relationships 5.15.2. SUPAPolicySource Relationships
SUPAPolicySource participates in a single relationship, SUPAPolicySource participates in a single relationship,
SUPAHasPolicySource, as defined in section 5.3.2.1. SUPAHasPolicySource, as defined in section 5.3.2.1.
SUPAPolicySource, and its subclasses, inherit the SUPAPolicySource, and its subclasses, inherit the
SUPAHasDecoratedPolicyComponent aggregation, which was SUPAHasPolicyMetadata aggregation, which is
defined in section 5.7.3. defined in section 5.17.2.1.
5.15. The Concrete Class "SUPAPolicyTarget" 5.16. The Concrete Class "SUPAPolicyTarget"
This is an optional class that defines a set of managed entities This is an optional class that defines a set of managed entities
that a SUPAPolicy is applied to. Figure 12 shows a class diagram that a SUPAPolicy is applied to. Figure 15 shows a class diagram
of the SUPAPolicyTarget. of the SUPAPolicyTarget.
A managed object must satisfy two conditions in order to be defined A managed object must satisfy two conditions in order to be defined
as a SUPAPolicyTarget. First, the set of managed entities that are as a SUPAPolicyTarget. First, the set of managed entities that are
to be affected by the SUPAPolicy must all agree to play the role of to be affected by the SUPAPolicy must all agree to play the role of
a SUPAPolicyTarget. In general, a managed entity may or may not be a SUPAPolicyTarget. In general, a managed entity may or may not be
in a state that enables SUPAPolicies to be applied to it to change in a state that enables SUPAPolicies to be applied to it to change
its state; hence, a negotiation process may need to occur to enable its state; hence, a negotiation process may need to occur to enable
the SUPAPolicyTarget to signal when it is willing to have the SUPAPolicyTarget to signal when it is willing to have
SUPAPolicies applied to it. Second, a SUPAPolicyTarget must be able SUPAPolicies applied to it. Second, a SUPAPolicyTarget must be able
skipping to change at page 80, line 24 skipping to change at page 87, line 38
If a proposed SUPAPolicyTarget meets both of these conditions, it If a proposed SUPAPolicyTarget meets both of these conditions, it
SHOULD set its supaPolicyTargetEnabled Boolean attribute to a SHOULD set its supaPolicyTargetEnabled Boolean attribute to a
value of TRUE. value of TRUE.
A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the
role-object pattern). This enables role-based access control to role-object pattern). This enables role-based access control to
be used to restrict which entities can author a given policy. be used to restrict which entities can author a given policy.
Note that Role is a type of SUPAPolicyMetadata. Note that Role is a type of SUPAPolicyMetadata.
5.15.1. SUPAPolicyTarget Attributes 5.16.1. SUPAPolicyTarget Attributes
Currently, no attributes are defined for the SUPAPolicyTarget Currently, no attributes are defined for the SUPAPolicyTarget
class. class.
5.15.2. SUPAPolicyTarget Relationships 5.16.2. SUPAPolicyTarget Relationships
SUPAPolicyTarget participates in a single relationship, SUPAPolicyTarget participates in a single relationship,
SUPAHasPolicyTarget, as defined in section 5.3.2.3. SUPAHasPolicyTarget, as defined in section 5.3.2.3. It also inherits
the SUPAHasPolicyMetadata aggregation (see section 5.17.2.1.).
5.16. The Abstract Class "SUPAPolicyMetadata" 5.17. The Abstract Class "SUPAPolicyMetadata"
Metadata is information that describes and/or prescribes Metadata is information that describes and/or prescribes
characteristics and behavior of another object that is **not** characteristics and behavior of another object that is **not**
an inherent, distinguishing characteristic or behavior of that an inherent, distinguishing characteristic or behavior of that
object (otherwise, it would be an integral part of that object). object (otherwise, it would be an integral part of that object).
For example, a socialSecurityNumber attribute should not be part For example, a socialSecurityNumber attribute should not be part
of a generic Person class. First, most countries in the world do of a generic Person class. First, most countries in the world do
not know what a social security number is, much less use them. not know what a social security number is, much less use them.
Second, a person is not created with a social security number; Second, a person is not created with a social security number;
skipping to change at page 81, line 31 skipping to change at page 89, line 5
SUPAPolicyMetadata objects are reused is by using the attributes SUPAPolicyMetadata objects are reused is by using the attributes
of the SUPAHasPolicyMetadataDetail association class. of the SUPAHasPolicyMetadataDetail association class.
It is recommended that this class, along with its It is recommended that this class, along with its
SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator
subclasses, be used as part of a conformant implementation. It is subclasses, be used as part of a conformant implementation. It is
defined to be optional, since metadata is not strictly required. defined to be optional, since metadata is not strictly required.
However, metadata can help specify and describe SUPAPolicyObject However, metadata can help specify and describe SUPAPolicyObject
entities, and can also be used to drive dynamic behavior. entities, and can also be used to drive dynamic behavior.
5.16.1. SUPAPolicyMetadata Attributes 5.17.1. SUPAPolicyMetadata Attributes
This section defines the attributes of the SUPAPolicyMetadata This section defines the attributes of the SUPAPolicyMetadata
class. class.
5.16.1.1. The Attribute "supaPolMetadataDescription" 5.17.1.1. The Attribute "supaPolMetadataDescription"
This is an optional string attribute that defines a free-form This is an optional string attribute that defines a free-form
textual description of this metadata object. textual description of this metadata object.
5.16.1.2. The Attribute "supaPolMetadataIDContent" 5.17.1.2. The Attribute "supaPolMetadataIDContent"
This is a mandatory string attribute that represents part of the This is a mandatory string attribute that represents part of the
object identifier of an instance of this class. It defines the object identifier of an instance of this class. It defines the
content of the object identifier. It works with another class content of the object identifier. It works with another class
attribute, called supaPolMetadataIDEncoding, which defines how to attribute, called supaPolMetadataIDEncoding, which defines how to
interpret this attribute. These two attributes form a tuple, interpret this attribute. These two attributes form a tuple,
and together enable a machine to understand the syntax and value and together enable a machine to understand the syntax and value
of an object identifier for the object instance of this class. of an object identifier for the object instance of this class.
5.16.1.3. The Attribute "supaPolMetadataIDEncoding" 5.17.1.3. The Attribute "supaPolMetadataIDEncoding"
This is an optional non-zero enumerated integer attribute that This is an optional non-zero enumerated integer attribute that
represents part of the object identifier of an instance of this represents part of the object identifier of an instance of this
class. It defines the format of the object identifier. It works class. It defines the format of the object identifier. It works
with another class attribute, called supaPolMetadataIDContent, with another class attribute, called supaPolMetadataIDContent,
which defines the content of the object ID. which defines the content of the object ID.
These two attributes form a tuple, and together enable a machine These two attributes form a tuple, and together enable a machine
to understand the syntax and value of an object identifier for to understand the syntax and value of an object identifier for
the object instance of this class. The supaPolMetadataIDEncoding the object instance of this class. The supaPolMetadataIDEncoding
attribute is mapped to the following values: attribute is mapped to the following values:
0: error 0: error (i.e., an error state)
1: init 1: init (i.e., an initialization state)
2: GUID 2: primary_key
3: UUID 3: foreign_key
4: URI 4: GUID
5: FQDN 5: UUID
6: FQPN 6: URI
7: string_instance_id 7: FQDN
8: FQPN
9: string_instance_id
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. Values 2-6 define the content as a reference. Value 7 respectively. Values 2-8 define the content as a reference. Value 9
defines the content as a string that is the canonical defines the content as a string that is the canonical
representation, in ASCII, of an instance ID of this object. representation, in ASCII, of an instance ID of this object.
5.16.1.4. The Attribute "supaPolMetadataName" 5.17.1.4. The Attribute "supaPolMetadataName"
This is an optional string attribute that defines the name of this This is an optional string attribute that defines the name of this
SUPAPolicyMetadata object. SUPAPolicyMetadata object.
5.16.2. SUPAPolicyMetadata Relationships 5.17.2. SUPAPolicyMetadata Relationships
SUPAPolicyMetadata participates in a single aggregation, which is SUPAPolicyMetadata participates in two aggregations. The first,
defined in the following subsections. SUPAHasPolicyMetadata, which is defined in the following subsection.
The second, SUPAHasMetadataDecorator, is defined in section 5.19.2.
5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" 5.17.2.1. The Aggregation "SUPAHasPolicyMetadata"
This is a mandatory aggregation that defines the set of This is a mandatory aggregation that defines the set of
SUPAPolicyMetadata that are aggregated by this particular SUPAPolicyMetadata that are aggregated by this particular
SUPAPolicyObject. It is recommended that this aggregation be used SUPAPolicyObject.
as part of a conformant implementation.
The multiplicity of this relationship is defined as 0..n on the The multiplicity of this relationship is defined as 0..n on the
aggregate (SUPAPolicyObject) side, and 0..n on the part aggregate (SUPAPolicyObject) side, and 0..n on the part
(SUPAPolicyMetadata) side. This means that this relationship is (SUPAPolicyMetadata) side. This means that this relationship is
optional. The semantics of this aggregation are implemented using optional. However, it is recommended that this aggregation be used
the SUPAHasPolicyMetadataDetail association class. as part of a conformant implementation, because it enables metadata
to be attached to all objects that inherit from the SUPAPolicyObject
class. The semantics of this aggregation are implemented using the
SUPAHasPolicyMetadataDetail association class.
5.16.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail" 5.17.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail"
This is a mandatory concrete association class, and defines the This is a mandatory concrete association class, and defines the
semantics of the SUPAHasPolicyMetadata aggregation. Its purpose is semantics of the SUPAHasPolicyMetadata aggregation. Its purpose is
to determine which SUPAPolicyMetadata object instances should be to determine which SUPAPolicyMetadata object instances should be
attached to which particular object instances of the attached to which particular object instances of the
SUPAPolicyObject class. This is done by using the attributes and SUPAPolicyObject class. This is done by using the attributes and
relationships of the SUPAPolicyMetadataDetail class to constrain relationships of the SUPAPolicyMetadataDetail class to constrain
which SUPAPolicyMetadata objects can be aggregated by which which SUPAPolicyMetadata objects can be aggregated by which
particular SUPAPolicyObject instances. It is recommended that this particular SUPAPolicyObject instances.
association class be used as part of a conformant implementation.
5.16.2.2.1. The Attribute "supaPolMetadataIsApplicable"
This is an optional Boolean attribute. If the value of this
attribute is TRUE, then the SUPAPolicyMetadata object(s) of this
particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated
by this particular SUPAPolicyObject.
5.16.2.2.2. The Attribute "supaPolMetadataConstraintEncoding" 5.17.2.2.1. The Attribute "supaPolMetadataConstraintEncoding"
This is an optional non-negative enumerated integer that defines This is an optional non-negative enumerated integer that defines
how to interpret each string in the supaPolMetadataConstraint how to interpret each string in the supaPolMetadataConstraint
class attribute. Values include: class attribute. Values include:
0: error 0: error
1: init 1: init
2: OCL 2.4 2: OCL 2.4
3: OCL 2.x 3: OCL 2.x
4: OCL 1.x 4: OCL 1.x
5: QVT 1.2 - Relations Language 5: QVT 1.2 - Relations Language
6: QVT 1.2 - Operational language 6: QVT 1.2 - Operational language
7: Alloy 7: Alloy
8: ASCII Text 8: ASCII Text
Enumerations 1 and 2 signify an error state and an initialization Enumerations 0 and 1 signify an error state and an initialization
state, respectively. Enumeraitons 3-5 are dedicated to OCL (with state, respectively. Enumerations 2-4 are dedicated to OCL (with
OCL 2.4 being the latest version as of this writing). QVT defines a OCL 2.4 being the latest version as of this writing). QVT defines a
set of languages [20] (the two most powerful and useful are defined set of languages [20] (the two most powerful and useful are defined
by enumerations 5 and 6). Alloy is a language for describing by enumerations 5 and 6). Alloy is a language for describing
constraints, and uses a SAT solver to guarantee correctness [21]. constraints, and uses a SAT solver to guarantee correctness [21].
Enumeration 8 (ASCII Text) is not recommended (since it is informal, Enumeration 8 (ASCII Text) is not recommended (since it is informal,
and hence, not verifiable), but is included for completeness. and hence, not verifiable), but is included for completeness.
If this class is instantiated, then this attribute SHOULD also be If this class is instantiated, then this attribute SHOULD also be
instantiated, and SHOULD be part of a conformant implementation. instantiated, and SHOULD be part of a conformant implementation.
5.16.2.2.3. The Attribute "supaPolMetadataConstraint[0..n]" 5.17.2.2.2. The Attribute "supaPolMetadataConstraint[0..n]"
This is an optional array of string attributes. Each attribute This is an optional array of string attributes. Each attribute
specifies a constraint to be applied using the format identified specifies a constraint to be applied using the format identified
by the value of the supaPolMetadataPolicyConstraintEncoding class by the value of the supaPolMetadataPolicyConstraintEncoding class
attribute. This provides a more rigorous and flexible treatment of attribute. This provides a more rigorous and flexible treatment of
constraints than is possible in [RFC3460]. constraints than is possible in [RFC3460].
If this class is instantiated, then this attribute SHOULD also be If this class is instantiated, then this attribute SHOULD also be
instantiated, and should be part of a conformant implementation. instantiated, and should be part of a conformant implementation.
Note: [0..n] means that this is a multi-valued property that has Note: [0..n] means that this is a multi-valued property that has
zero or more attributes. zero or more attributes.
5.17. The Concrete Class "SUPAPolicyConcreteMetadata" 5.17.2.2.3. The Attribute "supaPolMetadataIsApplicable"
This is an optional Boolean attribute. If the value of this
attribute is TRUE, then the SUPAPolicyMetadata object(s) of this
particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated
by this particular SUPAPolicyObject.
5.18. The Concrete Class "SUPAPolicyConcreteMetadata"
This is an optional concrete class. It defines an object that will This is an optional concrete class. It defines an object that will
be wrapped by concrete instances of the SUPAPolicyMetadataDecorator be wrapped by concrete instances of the SUPAPolicyMetadataDecorator
class. It can be viewed as a "carrier" for metadata that will be class. It can be viewed as a "carrier" for metadata that will be
attached to a subclass of SUPAPolicyObject. Since the decorator attached to a subclass of SUPAPolicyObject. Since the decorator
pattern is used, any number of concrete subclasses of the pattern is used, any number of concrete subclasses of the
SUPAPolicyMetadataDecorator class can wrap an instance of the SUPAPolicyMetadataDecorator class can wrap an instance of the
SUPAPolicyConcreteMetadata class. SUPAPolicyConcreteMetadata class.
It is recommended that this class be used as part of a conformant It is recommended that this class be used as part of a conformant
implementation. implementation.
5.17.1. SUPAPolicyConcreteMetadata Attributes 5.18.1. SUPAPolicyConcreteMetadata Attributes
Currently, two attributes are defined for the Currently, two attributes are defined for the
SUPAPolicyConcreteMetadata class, and are described in the SUPAPolicyConcreteMetadata class, and are described in the
following subsections. following subsections.
5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" 5.18.1.1. The Attribute "supaPolMDValidPeriodEnd"
This is an optional attribute. Its data type should be able to This is an optional attribute. Its data type should be able to
express a date and a time. This attribute defines the ending express a date and a time. This attribute defines the ending
date and time that this Metadata object is valid for. date and time that this Metadata object is valid for.
5.17.1.2. The Attribute "supaPolMDValidPeriodStart" 5.18.1.2. The Attribute "supaPolMDValidPeriodStart"
This is an optional attribute. Its data type should be able to This is an optional attribute. Its data type should be able to
express a date and a time. This attribute defines the starting express a date and a time. This attribute defines the starting
date and time that this Metadata object is valid for. date and time that this Metadata object is valid for.
5.17.2. SUPAPolicyConcreteMetadata Relationships 5.18.2. SUPAPolicyConcreteMetadata Relationships
This class inherits the relationships of the SUPAPolicyMetadata This class inherits the relationships of the SUPAPolicyMetadata
class; see section 5.16.2. It can also be used by subclasses of class; see section 5.17.2. It can also be used by subclasses of
the SUPAPolicyMetadataDecorator class, and hence, can participate the SUPAPolicyMetadataDecorator class, and hence, can participate
in the SUPAHasMetadataDecorator aggregation; see section 5.18.2. in the SUPAHasMetadataDecorator aggregation; see section 5.19.2.
5.18. The Abstract Class "SUPAPolicyMetadataDecorator" 5.19. The Abstract Class "SUPAPolicyMetadataDecorator"
This is an optional class, and is used to implement the decorator This is an optional class, and is used to implement the decorator
pattern (see section 5.7.1.) for metadata objects. This pattern pattern (see section 4.2.1.2.) for metadata objects. This pattern
enables all or part of one or more SUPAPolicyMetadataDecorator enables all or part of one or more SUPAPolicyMetadataDecorator
subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance. subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance.
It is recommended that this class be used as part of a conformant It is recommended that this class be used as part of a conformant
implementation. implementation.
5.18.1. SUPAPolicyMetadataDecorator Attributes 5.19.1. SUPAPolicyMetadataDecorator Attributes
Currently, no attributes are defined for the Currently, no attributes are defined for this class.
SUPAPolicyMetadataDecorator class.
5.18.2. SUPAPolicyMetadataDecorator Relationships 5.19.2. SUPAPolicyMetadataDecorator Relationships
This class inherits the relationships of the SUPAPolicyMetadata This class inherits the relationships of the SUPAPolicyMetadata
class; see section 5.16.2. It also defines a single aggregation, class; see section 5.17.2. It also defines a single aggregation,
SUPAHasMetadataDecorator, which is used to implement the decorator SUPAHasMetadataDecorator, which is used to implement the decorator
pattern, as described in the following subsections. pattern, as described in the following subsections.
5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" 5.19.2.1. The Aggregation "SUPAHasMetadataDecorator"
This is an optional aggregation, and is part of a decorator This is an optional aggregation, and is part of a decorator
pattern. It is used to enable a concrete instance of a pattern. It is used to enable a concrete instance of a
SUPAPolicyMetadataDecorator to dynamically add behavior to a SUPAPolicyMetadataDecorator to dynamically add behavior to a
SUPAPolicyConcreteMetadata object instance. The semantics of this SUPAPolicyConcreteMetadata object instance. The semantics of this
aggregation are defined by the SUPAHasMetadataDecoratorDetail aggregation are defined by the SUPAHasMetadataDecoratorDetail
association class. association class.
It is recommended that this aggregation be part of a conformant It is recommended that this aggregation be part of a conformant
implementation. implementation.
The multiplicity of this aggregation is 0..1 on the aggregate The multiplicity of this aggregation is 0..1 on the aggregate
(SUPAPolicyMetadataDecorator) side and 1..n on the part (SUPAPolicyMetadataDecorator) side and 1..n on the part
(SUPAPolicyMetadata) side. This means that if this aggregation is (SUPAPolicyMetadata) side. This means that if this aggregation is
defined, then at least one SUPAPolicyMetadata object (e.g., a defined, then at least one SUPAPolicyMetadata object (e.g., a
concrete subclass of SUPAPolicyMetadataDecorator) must also be concrete subclass of SUPAPolicyMetadataDecorator) must also be
instantiated and wrapped by this SUPAPolicyConcreteMetadata object instantiated and wrapped by this SUPAPolicyConcreteMetadata object
instance. The semantics of this aggregation are defined by the instance. The semantics of this aggregation are defined by the
SUPAHasMetadataDecoratorDetail association class. SUPAHasMetadataDecoratorDetail association class.
5.18.2.2. The Association Class "SUPAHasMetadataDecoratorDetail" 5.19.2.2. The Association Class "SUPAHasMetadataDecoratorDetail"
This is an optional concrete association class, and defines the This is an optional concrete association class, and defines the
semantics of the SUPAHasMetadataDecorator aggregation. The purpose semantics of the SUPAHasMetadataDecorator aggregation. The purpose
of this class is to use the Decorator pattern to determine of this class is to use the Decorator pattern to determine
which SUPAPolicyMetadataDecorator object instances, if any, are which SUPAPolicyMetadataDecorator object instances, if any, are
required to augment the functionality of the required to augment the functionality of the
SUPAPolicyConcreteMetadata object instance that is being used. SUPAPolicyConcreteMetadata object instance that is being used.
Three attributes are defined for this class, which are described
in the following subsections.
It is recommended that this association class be part of a It is recommended that this association class be part of a
conformant implementation. conformant implementation.
Attributes for this association class will be defined in a future 5.19.2.2.1. The Attribute "supaPolMetadataDecConstraintEncoding"
version of this document.
5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" This is an optional non-negative enumerated integer that defines
how to interpret each string in the supaPolMetadataDecConstraint
class attribute. Values include:
0: error
1: init
2: OCL 2.4
3: OCL 2.x
4: OCL 1.x
5: QVT 1.2 - Relations Language
6: QVT 1.2 - Operational language
7: Alloy
8: ASCII Text
Enumerations 0 and 1 signify an error state and an initialization
state, respectively. Enumerations 2-4 are dedicated to OCL (with
OCL 2.4 being the latest version as of this writing). QVT defines a
set of languages [20] (the two most powerful and useful are defined
by enumerations 5 and 6). Alloy is a language for describing
constraints, and uses a SAT solver to guarantee correctness [21].
Enumeration 8 (ASCII Text) is not recommended (since it is informal,
and hence, not verifiable), but is included for completeness.
If this class is instantiated, then this attribute SHOULD also be
instantiated, and SHOULD be part of a conformant implementation.
5.19.2.2.2. The Attribute "supaPolMetadataDecConstraint[0..n]"
This is an optional array of string attributes. Each attribute
specifies a constraint to be applied using the format identified
by the value of the supaPolMetadataDecConstraintEncoding class
attribute. This provides a more rigorous and flexible treatment of
constraints than is possible in [RFC3460].
If this class is instantiated, then this attribute SHOULD also be
instantiated, and should be part of a conformant implementation.
Note: [0..n] means that this is a multi-valued property that has
zero or more attributes.
5.19.2.2.3. The Attribute "supaPolMetadataDecIsApplicable"
This is an optional Boolean attribute. If the value of this
attribute is TRUE, then the SUPAPolicyMetadataDecorator object(s) of
this particular SUPAHasMetadataDecorator aggregation SHOULD be
aggregated by this particular SUPAPolicyConcreteMetadata object.
5.20. The Concrete Class "SUPAPolicyAccessMetadataDef"
This is an optional concrete class that defines access control This is an optional concrete class that defines access control
information, in the form of metadata, that can be added to a information, in the form of metadata, that can be added to a
SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata
aggregation (see section 5.2.2.). This enables all or part of a aggregation (see section 5.2.2.). This enables all or part of a
standardized description and/or specification of access control standardized description and/or specification of access control
for a given SUPAPolicyObject to be easily changed at runtime by for a given SUPAPolicyObject to be easily changed at runtime by
wrapping an object instance of the SUPAPolicyConcreteMetadata wrapping an object instance of the SUPAPolicyConcreteMetadata
class (or its subclass) with all or part of this object, and then class (or its subclass) with all or part of this object, and then
adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata
object instance. object instance.
5.19.1. SUPAPolicyAccessMetadataDef Attributes 5.20.1. SUPAPolicyAccessMetadataDef Attributes
Currently, the SUPAPolicyAccessMetadataDef class defines three Currently, the SUPAPolicyAccessMetadataDef class defines three
attributes; these are described in the following subsections. attributes; these are described in the following subsections.
5.19.1.1. The Attribute "supaPolAccessPrivilegeDef" 5.20.1.1. The Attribute "supaPolAccessPrivilegeDef"
This is an optional non-negative enumerated integer attribute. It This is an optional non-negative enumerated integer attribute. It
specifies the access privileges that external Applications have specifies the access privileges that external Applications have
when interacting with a specific SUPAPolicyObject that is adorned when interacting with a specific SUPAPolicyObject that is adorned
with an instance of this SUPAPolicyAccessMetadataDef object. This with an instance of this SUPAPolicyAccessMetadataDef object. This
enables the management system to control, in a consistent manner, enables the management system to control, in a consistent manner,
the set of operations that external Applications have for the set of operations that external Applications have for
SUPAPolicies and components of SUPAPolicies. Values include: SUPAPolicies and components of SUPAPolicies. Values include:
0: error 0: error
skipping to change at page 87, line 8 skipping to change at page 95, line 24
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. Values 4-8 indicate that a formal external access respectively. Values 4-8 indicate that a formal external access
control model is used. The name of this model, and its location, control model is used. The name of this model, and its location,
are specified in two other class attributes, called are specified in two other class attributes, called
supaPolAccessPrivilegeModelName and supaPolAccessPrivilegeModelRef. supaPolAccessPrivilegeModelName and supaPolAccessPrivilegeModelRef.
MAC, DAC, RBAC, and ABAC (values 4-7 stand for Mandatory Access MAC, DAC, RBAC, and ABAC (values 4-7 stand for Mandatory Access
Control, Discretionary Access Control, Role-Based Access Control, Control, Discretionary Access Control, Role-Based Access Control,
and Attribute-Based Access Control, respectively. They are defined and Attribute-Based Access Control, respectively. They are defined
in [22]. A value of 8 indicates that a formal external model that in [13]. A value of 8 indicates that a formal external model that
is not MAC, DAC, RBAC, or ABAC is used. is not MAC, DAC, RBAC, or ABAC is used.
5.19.1.2. The Attribute "supaPolAccessPrivilegeModelName" 5.20.1.2. The Attribute "supaPolAccessPrivilegeModelName"
This is an optional string attribute that contains the name of This is an optional string attribute that contains the name of
the access control model being used. If the value of the the access control model being used. If the value of the
supaPolAccessPrivilegeDef is 0-2, then the value of this attribute supaPolAccessPrivilegeDef is 0-2, then the value of this attribute
is not applicable. Otherwise, the text in this class attribute is not applicable. Otherwise, the text in this class attribute
should be interpreted according to the value of the should be interpreted according to the value of the
supaPolAccessPrivilegeModelRef class attribute. supaPolAccessPrivilegeModelRef class attribute.
5.19.1.3. The Attribute "supaPolAccessPrivilegeModelRef" 5.20.1.3. The Attribute "supaPolAccessPrivilegeModelRef"
This is an optional non-negative enumerated integer attribute This is an optional non-negative enumerated integer attribute
that defines the data type of the supaPolAccessPrivilegeModelName that defines the data type of the supaPolAccessPrivilegeModelName
attribute. If the value of the supaPolAccessPrivilegeDef class attribute. If the value of the supaPolAccessPrivilegeDef class
attribute is 0-2, then the value of this attribute is not attribute is 0-2, then the value of this attribute is not
applicable. Otherwise, the value of this class attribute defines applicable. Otherwise, the value of this class attribute defines
how to interpret the text in the supaPolAccessPrivilegeModelRef how to interpret the text in the supaPolAccessPrivilegeModelRef
class attribute. Values include: class attribute. Values include:
0: error 0: error
skipping to change at page 87, line 44 skipping to change at page 96, line 10
4: URI 4: URI
5: FQDN 5: FQDN
6: FQPN 6: FQPN
7: string_instance_id 7: string_instance_id
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. Values 2-6 define the content as a reference. Value 7 respectively. Values 2-6 define the content as a reference. Value 7
defines the content as a string that is the canonical defines the content as a string that is the canonical
representation, in ASCII, of an instance ID of this object. representation, in ASCII, of an instance ID of this object.
5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" 5.21. The Concrete Class "SUPAPolicyVersionMetadataDef"
This is an optional concrete class that defines versioning This is an optional concrete class that defines versioning
information, in the form of metadata, that can be added to a information, in the form of metadata, that can be added to a
SUPAPolicyObject. This enables all or part of a standardized SUPAPolicyObject. This enables all or part of a standardized
description and/or specification of version information for a description and/or specification of version information for a
given SUPAPolicyObject to be easily changed at runtime by given SUPAPolicyObject to be easily changed at runtime by
wrapping an object instance of the SUPAPolicyConcreteMetadata wrapping an object instance of the SUPAPolicyConcreteMetadata
class (or its subclass) with all or part of this object. class (or its subclass) with all or part of this object.
5.20.1. SUPAPolicyVersionMetadataDef Attributes 5.21.1. SUPAPolicyVersionMetadataDef Attributes
Version information is defined in a generic format based on the Version information is defined in a generic format based on the
Semantic Versioning Specification [18] as follows: Semantic Versioning Specification [18] as follows:
<major>.<minor>.<patch>[<pre-release>][<build-metadata>] <major>.<minor>.<patch>[<pre-release>][<build-metadata>]
where the first three components (major, minor, and patch) MUST be where the first three components (major, minor, and patch) MUST be
present, and the latter two components (pre-release and build- present, and the latter two components (pre-release and build-
metadata) MAY be present. A version number MUST take the form metadata) MAY be present. A version number MUST take the form
<major>.<minor>.<patch>, where <major>, <minor>, and <patch> are <major>.<minor>.<patch>, where <major>, <minor>, and <patch> are
each non-negative integers that MUST NOT contain leading zeros. each non-negative integers that MUST NOT contain leading zeros.
In addition, the value of each of these three elements MUST In addition, the value of each of these three elements MUST
increase numerically. increase numerically. In this approach:
In this approach:
o supaVersionMajor denotes a new release; this number MUST be o supaVersionMajor denotes a new release; this number MUST be
incremented when either changes are introduced that are not incremented when either changes are introduced that are not
backwards-compatible, and/or new functionality not previously backwards-compatible, and/or new functionality not previously
present is introduced present is introduced
o supaVersionMinor denotes a minor release; this number MUST be o supaVersionMinor denotes a minor release; this number MUST be
incremented when new features and/or bug fixes to a major incremented when new features and/or bug fixes to a major
release that are backwards-compatible are introduced, and/or release that are backwards-compatible are introduced, and/or
if any features are marked as deprecated if any features are marked as deprecated
o supaVersionPatch denotes a version that consists ONLY of bug o supaVersionPatch denotes a version that consists ONLY of bug
skipping to change at page 89, line 16 skipping to change at page 97, line 31
than non-numeric identifiers than non-numeric identifiers
- A larger set of pre-release fields has a higher - A larger set of pre-release fields has a higher
precedence than a smaller set, if all of the precedence than a smaller set, if all of the
preceding identifiers are equal preceding identifiers are equal
3. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha-beta 3. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha-beta
< 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0. < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0.
Currently, the SUPAPolicyVersionMetadataDef class defines five Currently, the SUPAPolicyVersionMetadataDef class defines five
attributes; these are described in the following subsections. attributes; these are described in the following subsections.
5.20.1.1. The Attribute "supaVersionMajor" 5.21.1.1. The Attribute "supaVersionMajor"
This is a mandatory string attribute, and contains a string This is a mandatory string attribute, and contains a string
representation of an integer that is greater than or equal to zero. representation of an integer that is greater than or equal to zero.
It indicates that a significant increase in functionality is It indicates that a significant increase in functionality is
present in this version. It MAY also indicate that this version has present in this version. It MAY also indicate that this version has
changes that are NOT backwards-compatible; this MAY be denoted in changes that are NOT backwards-compatible; this MAY be denoted in
the supaVersionBuildMetadata class attribute. the supaVersionBuildMetadata class attribute.
The special string "0.1.0" is for initial development that MUST The special string "0.1.0" is for initial development that MUST
NOT be considered stable. Improvements to this initial version, NOT be considered stable. Improvements to this initial version,
before they are released to the public, are denoted by incrementing before they are released to the public, are denoted by incrementing
the minor and patch version numbers. the minor and patch version numbers.
The major version X (i.e., X.y.z, where X > 0) MUST be incremented The major version X (i.e., X.y.z, where X > 0) MUST be incremented
if any backwards incompatible changes are introduced. It MAY if any backwards incompatible changes are introduced. It MAY
include minor and patch level changes. The minor and patch version include minor and patch level changes. The minor and patch version
numbers MUST be reset to 0 when the major version number is numbers MUST be reset to 0 when the major version number is
incremented. incremented.
5.20.1.2. The Attribute "supaVersionMinor" 5.21.1.2. The Attribute "supaVersionMinor"
This is a mandatory string attribute, and contains a string This is a mandatory string attribute, and contains a string
representation of an integer that is greater than or equal to zero. representation of an integer that is greater than or equal to zero.
It indicates that this release contains a set of features and/or It indicates that this release contains a set of features and/or
bug fixes that MUST be backwards-compatible. bug fixes that MUST be backwards-compatible.
The minor version Y (i.e., x.Y.z, where x > 0) MUST be incremented The minor version Y (i.e., x.Y.z, where x > 0) MUST be incremented
if new, backwards-compatible changes are introduced. It MUST be if new, backwards-compatible changes are introduced. It MUST be
incremented if any features are marked as deprecated. It MAY be incremented if any features are marked as deprecated. It MAY be
incremented if new functionality or improvements are introduced. incremented if new functionality or improvements are introduced.
It MAY include patch level changes. The patch version number MUST It MAY include patch level changes. The patch version number MUST
be reset to 0 when the minor version number is incremented. be reset to 0 when the minor version number is incremented.
5.20.1.3. The Attribute "supaVersionPatch" 5.21.1.3. The Attribute "supaVersionPatch"
This is a mandatory string attribute, and contains a string This is a mandatory string attribute, and contains a string
representation of an integer that is greater than or equal to zero. representation of an integer that is greater than or equal to zero.
It indicates that this version contains ONLY bug fixes. It indicates that this version contains ONLY bug fixes.
The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented
if new, backwards-compatible changes are introduced. A bug fix is if new, backwards-compatible changes are introduced. A bug fix is
defined as an internal change that fixes incorrect behavior. defined as an internal change that fixes incorrect behavior.
5.20.1.4. The Attribute "supaVersionPreRelease" 5.21.1.4. The Attribute "supaVersionPreRelease"
This is an optional string attribute, and contains a string This is an optional string attribute, and contains a string
defining the pre-release version. defining the pre-release version.
A pre-release version MAY be denoted by appending a hyphen and a A pre-release version MAY be denoted by appending a hyphen and a
series of dot-separated identifiers immediately following the patch series of dot-separated identifiers immediately following the patch
version. Identifiers MUST comprise only ASCII alphanumerics and a version. Identifiers MUST comprise only ASCII alphanumerics and a
hyphen. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT hyphen. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT
include leading zeroes. Pre-release versions have a lower include leading zeroes. Pre-release versions have a lower
precedence than the associated normal version. A pre-release version precedence than the associated normal version. A pre-release version
indicates that the version is unstable and might not satisfy the indicates that the version is unstable and might not satisfy the
intended compatibility requirements as denoted by its associated intended compatibility requirements as denoted by its associated
normal version. Examples include: 1.0.0-alpha, normal version. Examples include: 1.0.0-alpha,
1.0.0-alpha.1, 1.0.0-0.3.7, and 1.0.0-x.7.z.92. 1.0.0-alpha.1, 1.0.0-0.3.7, and 1.0.0-x.7.z.92.
5.20.1.5. The Attribute "supaVersionBuildMetadata" 5.21.1.5. The Attribute "supaVersionBuildMetadata"
This is an optional string attribute, and contains a string defining This is an optional string attribute, and contains a string defining
the build metadata. Build metadata MAY be denoted by appending a the build metadata. Build metadata MAY be denoted by appending a
plus sign and a series of dot-separated identifiers immediately plus sign and a series of dot-separated identifiers immediately
following the patch or pre-release version. Identifiers MUST be following the patch or pre-release version. Identifiers MUST be
made up of only ASCII alphanumerics and a hyphen. Identifiers made up of only ASCII alphanumerics and a hyphen. Identifiers
MUST NOT be empty. Build metadata SHOULD be ignored when determining MUST NOT be empty. Build metadata SHOULD be ignored when determining
version precedence. Examples include: 1.0.0.-alpha+1, version precedence. Examples include: 1.0.0.-alpha+1,
1.0.0+20130313144700, and 1.0.0-beta+exp.sha.5114f85. 1.0.0+20130313144700, and 1.0.0-beta+exp.sha.5114f85.
skipping to change at page 91, line 17 skipping to change at page 99, line 17
This section defines the classes, attributes, and relationships This section defines the classes, attributes, and relationships
of the SUPA ECAPolicyRule Information Model (EPRIM). Unless of the SUPA ECAPolicyRule Information Model (EPRIM). Unless
otherwise stated, all classes (and attributes) defined in this otherwise stated, all classes (and attributes) defined in this
section were abstracted from DEN-ng [2], and a version of them are section were abstracted from DEN-ng [2], and a version of them are
in the process of being added to [5]. in the process of being added to [5].
6.1. Overview 6.1. Overview
Conceptually, the EPRIM is a set of subclasses that specialize the Conceptually, the EPRIM is a set of subclasses that specialize the
concepts defined in the GPIM for representing the components of a concepts defined in the GPIM for representing the components of a
Policy that uses ECA semantics. This is shown in Figure 23 (only Policy that uses ECA semantics. This is shown in Figure 26 (only
new EPRIM subclasses and their GPIM superclasses are shown; note new EPRIM subclasses and their GPIM superclasses are shown; note
that the SUPAPolicyMetadata hierarchy is used **as is**). that the SUPAPolicyMetadata hierarchy is used **as is**).
(Class of another model that SUPA is integrating into) (Class of another model that SUPA is integrating into)
| |
+---SUPAPolicyObject (5.2) +---SUPAPolicyObject (5.2)
| |
+---SUPAPolicyStructure (5.3) +---SUPAPolicyStructure (5.3)
| | | |
| +---SUPAECAPolicyRule (6.4) | +---SUPAECAPolicyRule (6.4)
| | | |
| +---SUPAECAPolicyRuleAtomic (6.5) | +---SUPAECAPolicyRuleAtomic (6.5)
| | | |
| +---SUPAECAPolicyRuleComposite (6.6) | +---SUPAECAPolicyRuleComposite (6.6)
| |
+---SUPAPolicyComponentStructure (5.6) +---SUPAPolicyComponentStructure (5.4)
| |
+---SUPAPolicyClause (5.7) +---SUPAPolicyClause (5.5)
| | | |
| +---SUPABooleanClause (6.7) | +---SUPABooleanClause (6.7)
| | | |
| +---SUPAECAPolicyRuleAtomic (6.8) | +---SUPABooleanClauseAtomic (6.8)
| | | |
| +---SUPAECAPolicyRuleComposite (6.9) | +---SUPABooleanClauseComposite (6.9)
| |
+---SUPAPolicyComponentDecorator (5.9) +---SUPAPolicyClauseComponentDecorator (5.7)
| |
+---SUPAECAComponent(6.10) +---SUPAECAComponent(6.10)
| |
+---SUPAPolicyEvent (6.11) +---SUPAPolicyEvent (6.11)
| |
+---SUPAPolicyCondition (6.12) +---SUPAPolicyCondition (6.12)
| |
+---SUPAPolicyAction (6.13) +---SUPAPolicyAction (6.13)
Figure 23. The EPRIM Class Hierarchy Figure 26. The EPRIM Class Hierarchy
Specifically, the EPRIM specializes the SUPAPolicyStructure class Specifically, the EPRIM specializes the SUPAPolicyStructure class
class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it
also specializes two subclasses of the SUPAPolicyComponentStructure also specializes two subclasses of the SUPAPolicyComponentStructure
class to create two new sets of policy components. These two class to create two new sets of policy components. These two
SUPAPolicyComponentStructure subclasses are: SUPAPolicyComponentStructure subclasses are:
o a new subclass of SUPAPolicyClause, called SUPABooleanClause o a new subclass of SUPAPolicyClause, called SUPABooleanClause
(see sections 6.7 - 6.9), is defined for constructing Boolean (see sections 6.7 - 6.9), is defined for constructing Boolean
clauses that are specific to the needs of ECA Policy Rules clauses that are specific to the needs of ECA Policy Rules
o a new subclass of SUPAPolicyComponentDecorator, called o a new subclass of SUPAPolicyClauseComponentDecorator, called
SUPAECAComponent (see sections 6.10 - 6.13), is defined for SUPAECAComponent (see sections 6.10 - 6.13), is defined for
constructing reusable objects that represent Events, constructing reusable objects that represent Events,
Conditions, and Actions Conditions, and Actions
The EPRIM provides new functionality, based on the GPIM, by The EPRIM provides new functionality, based on the GPIM, by
extending the GPIM to define new classes and relationships. The extending the GPIM to define new classes and relationships. The
EPRIM does NOT define new classes that are not inherited from EPRIM does NOT define new classes that are not inherited from
existing GPIM classes. This ensures that the semantics of the GPIM existing GPIM classes. This ensures that the semantics of the GPIM
are not changed, even though new functionality (for ECA Policy are not changed, even though new functionality (for ECA Policy
Rules and components) are being defined. Rules and components) are being defined.
skipping to change at page 93, line 15 skipping to change at page 101, line 15
6.2. Constructing a SUPAECAPolicyRule 6.2. Constructing a SUPAECAPolicyRule
There are several different ways to construct a SUPAECAPolicyRule; There are several different ways to construct a SUPAECAPolicyRule;
they differ in which set of components are used to define the they differ in which set of components are used to define the
content of the SUPAECAPolicyRule, and whether each component is content of the SUPAECAPolicyRule, and whether each component is
decorated or not. The following are some examples of creating a decorated or not. The following are some examples of creating a
SUPAECAPolicyRule: SUPAECAPolicyRule:
o Define three types of SUPABooleanClauses, one each for the o Define three types of SUPABooleanClauses, one each for the
event, condition, and action clauses that make up a event, condition, and action clauses that make up a
SUPAECAPolicyRule SUPAECAPolicyRule, and then
o For one or more of the above clauses, associate an o For one or more of the above clauses, associate an
appropriate set of SUPAPolicyEvent, SUPAPolicyCondition, or appropriate set of SUPAPolicyEvent, SUPAPolicyCondition, or
SUPAPolicyAction objects, and complete the clause using an SUPAPolicyAction objects, and complete the clause using an
appropriate SUPAPolicyOperator and a corresponding appropriate SUPAPolicyOperator and a corresponding
SUPAPolicyValue or SUPAPolicyVariable SUPAPolicyValue or SUPAPolicyVariable (e.g., resulting in
o Note that compound Boolean clauses may be formed using the phrase "SUPAPolicyAction = SUPAPolicyEvent")
one or more SUPABooleanClauseComposite objects with one or
more SUPABooleanClauseAtomic objects
o Define a SUPAPolicyCollection component, which is used to o Define a SUPAPolicyCollection component, which is used to
aggregate a set of objects appropriate for a clause, and aggregate a set of objects appropriate for a clause, and
complete the clause using an appropriate SUPAPolicyOperator complete the clause using an appropriate SUPAPolicyOperator
and a corresponding SUPAPolicyValue or SUPAPolicyVariable and a corresponding SUPAPolicyValue or SUPAPolicyVariable
o Create a new concrete subclass of SUPAPolicyComponentStructure o Create a new concrete subclass of
(i.e., a sibling class of SUPAPolicyComponentDecorator and SUPAPolicyClauseComponentDecorator (i.e., a sibling class of
SUPAPolicyClause), and use this new subclass in a concrete SUPAECAComponent) that can wrap concrete instances of
subclass of SUPABooleanClause; note that this approach enables SUPAPolicyClause (i.e., SUPABooleanClause); note that this
the new concrete subclass of SUPAPolicyComponentStructure to approach enables the new concrete subclass of
optionally be decorated as well SUPAPolicyClauseComponentDecorator to optionally be decorated
o Create a new subclass of SUPAPolicyComponentDecorator (e.g., as well
a sibling of SUPAECAComponent) that provides ECA-specific
functionality, and use that to decorate a SUPAPolicyClause
o Create a new concrete subclass of SUPAPolicyStructure that o Create a new concrete subclass of SUPAPolicyStructure that
provides ECA-specific functionality, and define all or part provides ECA-specific functionality, and define all or part
of its content by aggregating a set of SUPAPolicyClauses of its content by aggregating a set of SUPAPolicyClauses
Note that compound Boolean clauses may be formed using one or more
SUPABooleanClauseComposite objects with one or more
SUPABooleanClauseAtomic objects.
6.3. Working With SUPAECAPolicyRules 6.3. Working With SUPAECAPolicyRules
A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that
MUST have three clauses, defined as follows: MUST have three clauses, defined as follows:
o The event clause defines a Boolean expression that, if TRUE, o The event clause defines a Boolean expression that, if TRUE,
triggers the evaluation of its condition clause (if the triggers the evaluation of its condition clause (if the
event clause is not TRUE, then no further action for this event clause is not TRUE, then no further action for this
policy rule takes place). policy rule takes place).
o The condition clause defines a Boolean expression that, if o The condition clause defines a Boolean expression that, if
TRUE, enables the actions in the action clause to be executed TRUE, enables the actions in the action clause to be executed
(if the condition clause is not TRUE, then no further action (if the condition clause is not TRUE, then no further action
for this policy rule takes place). for this policy rule takes place).
o The action clause contains a set of actions (note that an
action MAY invoke another SUPAECAPolicyRule; see section o The action clause contains a set of actions that MAY be
6.13). executed; which particular actions are executed are defined
by metadata and the supaECAEvalStrategy attribute (see
section 6.6.1.1.).
Each of the above clauses can be a simple Boolean expression (of Each of the above clauses can be a simple Boolean expression (of
the form {variable operator value}, or a compound Boolean the form {variable operator value}, or a compound Boolean
expression consisting of Boolean combinations of clauses. expression consisting of Boolean combinations of clauses.
Compound Boolean expressions SHOULD be in CNF or DNF. Compound Boolean expressions SHOULD be in CNF or DNF.
Note that each of the above three clauses MAY have a set of Note that each of the above three clauses MAY have a set of
SUPAPolicyMetadata objects that can constrain, or otherwise SUPAPolicyMetadata objects that can constrain, or otherwise
affect, how that clause is treated. For example, a set of affect, how that clause is treated. For example, a set of
SUPAPolicyMetadata MAY affect whether none, some, or all actions SUPAPolicyMetadata MAY affect whether none, some, or all actions
skipping to change at page 94, line 25 skipping to change at page 102, line 30
Each of the three clauses can be constructed from either a Each of the three clauses can be constructed from either a
SUPAEncodedClause or a SUPABooleanClause. The advantage of using SUPAEncodedClause or a SUPABooleanClause. The advantage of using
SUPAEncodedClauses is simplicity, as the content of the clause is SUPAEncodedClauses is simplicity, as the content of the clause is
encoded directly into the attributes of the SUPAEncodedClause. The encoded directly into the attributes of the SUPAEncodedClause. The
advantage of using SUPABooleanClauses is reusability, since each advantage of using SUPABooleanClauses is reusability, since each
term in each clause is potentially a reusable object. term in each clause is potentially a reusable object.
Since a SUPABooleanClause is a subclass of a SUPAPolicyClause Since a SUPABooleanClause is a subclass of a SUPAPolicyClause
(see Section 6.7), it can be decorated by one or more concrete (see Section 6.7), it can be decorated by one or more concrete
subclasses of SUPAPolicyComponentDecorator. Therefore, a subclasses of SUPAPolicyClauseComponentDecorator. Therefore, a
SUPAECAPolicyRule can be built entirely from objects defined in SUPAECAPolicyRule can be built entirely from objects defined in
the GPIM and EPRIM, which facilitates the construction of the GPIM and EPRIM, which facilitates the construction of
SUPAPolicies by a machine. SUPAPolicies by a machine.
The relation between a SUPAECAPolicyRule and a SUPAPolicyClause The relation between a SUPAECAPolicyRule and a SUPAPolicyClause
is shown in Figure 24, and is explained in further detail in is shown in Figure 27, and is further explained in Section 6.4.
Section 6.4.
SUPAHasPolicyClause A A
+----------------+------------------------+ +---------------------+ +------------------+
| ^ | | |/ \ SUPAHasPolicyClause \| |
| | | | SUPAPolicyStructure | A ---------+------------+ SUPAPolicyClause |
/ \ | | | |\ / ^ /| |
A | | +---------+-----------+ 0..n | 1..n +--------+---------+
A \ / 0..1 | A 1..n \ / / \ | / \
+----------+-----------+ | +-----------+------+ I | I
| SUPAPolicyStructure | | | SUPAPolicyClause | A I | A I
+----------+-----------+ | +-----------+------+ +-------+-----------+ | +--------+----------+
/ \ | / \ | SUPAECAPolicyRule | | | SUPABooleanClause |
I A | | +-------------------+ | +-------------------+
I +----------+----------------+ | |
I | SUPAHasPolicyClauseDetail | | A |
I +---------------------------+ | +---------------+-----------+
I | | SUPAHasPolicyClauseDetail |
C I A | +---------------------------+
+----------+----------+ +--------+----------+
| SUPAECAPolicyRule | | SUPABooleanClause |
+---------------------+ +-------------------+
Figure 24. SUPAECAPolicyRule Clauses Figure 27. SUPAECAPolicyRule Clauses
The SUPAHasPolicyClause aggregation is implemented using the The SUPAHasPolicyClause aggregation is implemented using the
SUPAHasPolicyClauseDetail association class. These were SUPAHasPolicyClauseDetail association class. These were
described in sections 5.4.2.1 and 5.4.2.2, respectively. described in sections 5.3.2.7 and 5.3.2.8, respectively.
6.4. The Abstract Class "SUPAECAPolicyRule" 6.4. The Abstract Class "SUPAECAPolicyRule"
This is a mandatory abstract class, which is a PolicyContainer This is a mandatory abstract class, which is a PolicyContainer
that aggregates PolicyEvents, PolicyConditions, PolicyActions into that aggregates PolicyEvents, PolicyConditions, PolicyActions into
a type of policy rule known as an Event-Condition-Action (ECA) a type of policy rule known as an Event-Condition-Action (ECA)
policy rule. As previously explained, this has the following policy rule. As previously explained, this has the following
semantics: semantics:
IF the event clause evaluates to TRUE IF the event clause evaluates to TRUE
IF the condition clause evaluates to TRUE IF the condition clause evaluates to TRUE
THEN execute actions in the action clause THEN execute actions in the action clause
ENDIF ENDIF
ENDIF ENDIF
The event clause, condition clause, and action clause collectively The event clause, condition clause, and action clause collectively
form a three-tuple. Each clause MUST be defined by at least one form a three-tuple. Each clause MUST be defined by at least one
SUPAPolicyClause (which MAY be decorated with other elements, SUPAPolicyClause (which MAY be decorated with other elements,
as described in section 5.7). using concrete subclasses of the SUPAPolicyClauseComponentDecorator
class, as described in section 5.7).
Each of the three types of clauses is a 3-tuple of the form: Each of the three types of clauses is a 3-tuple of the form:
{variable operator value} {variable operator value}
Each of the three clauses MAY be combined with additional clauses Each of the three clauses MAY be combined with additional clauses
using any combination of logical AND, OR, and NOT operators; this using any combination of logical AND, OR, and NOT operators; this
forms a "compound" Boolean clause. For example, if A, B, and C are forms a "compound" Boolean clause. For example, if A, B, and C are
three attributes in an event, then a valid event clause could be: three attributes in an event, then a valid event clause could be:
(A AND B) OR C (A AND B) OR C
Note that the above expression is in DNF; the equivalent CNF form Note that the above expression is in DNF; the equivalent CNF form
is ((A OR C) AND (B OR C)). In either case, the output of all is ((A OR C) AND (B OR C)). In either case, the output of all
three clauses is either TRUE or FALSE; this facilitates combining three clauses is either TRUE or FALSE; this facilitates combining
and chaining SUPAECAPolicyRules. and chaining SUPAECAPolicyRules.
An action clause MAY invoke a new SUPAECAPolicyRule; see section An action clause MAY invoke a SUPAPolicyAction from the same or a
6.13 for more details. different SUPAECAPolicyRule. However, a SUPAPolicy MUST NOT be
called directly by a SUPAECAPolicyRule action clause; this is
because the semantics of a SUPAECAPolcyRule dictate that some type
of event triggers its evaluation (among other reasons).
An ECAPolicyRule MAY be optionally augmented with PolicySources An ECAPolicyRule MAY be optionally augmented with SUPAPolicySource
and/or PolicyTargets (see sections 5.16 and 5.17, respectively). and/or SUPAPolicyTarget objects (see sections 5.15 and 5.16,
In addition, all objects that make up a SUPAECAPolicyRule MAY respectively).
have SUPAPolicyMetadata (see section 5.16) attached to them to
All objects that make up a SUPAECAPolicyRule MAY have
SUPAPolicyMetadata objects (see section 5.17) attached to them to
further describe and/or specify behavior. further describe and/or specify behavior.
When defined in an information model, each of the event, condition, When defined in an information model, each of the event, condition,
and action clauses MUST be represented as an aggregation between a and action clauses MUST be represented as an aggregation between a
SUPAECAPolicyRule (the aggregate) and a set of event, condition, SUPAECAPolicyRule (the aggregate) and a set of event, condition,
or action objects (the components). However, a data model MAY map or action objects (the components). However, a data model MAY map
these definitions to a more efficient form (e.g., by flattening these definitions to a more efficient form (e.g., by flattening
these three types of object instances, along with their respective these three types of object instances, along with their respective
aggregations, into a single object instance). aggregations, into a single object instance).
skipping to change at page 96, line 26 skipping to change at page 104, line 34
SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both
inherit from SUPAECAPolicyRule. This means that they are both inherit from SUPAECAPolicyRule. This means that they are both
a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule
aggregation enables a particular SUPAECAPolicyRuleComposite aggregation enables a particular SUPAECAPolicyRuleComposite
object to aggregate both SUPAECAPolicyRuleComposite as well as object to aggregate both SUPAECAPolicyRuleComposite as well as
SUPAECAPolicyRuleAtomic objects. In contrast, a SUPAECAPolicyRuleAtomic objects. In contrast, a
SUPAECAPolicyRuleAtomic can NOT aggregate either a SUPAECAPolicyRuleAtomic can NOT aggregate either a
SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic.
SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are
defined in sections 6.5 and 6.6, respectively. This is defined in sections 6.5 and 6.6, respectively. This is
shown in Figure 25. shown in Figure 28.
A A
1..n +-------------------+ 1..n +-------------------+
\| | \| |
+--------------- + SUPAECAPolicyRule | +--------------- + SUPAECAPolicyRule |
| /| | | /| |
| +--------+----------+ | +--------+----------+
| / \ | / \
| SUPAHasECAPolicyRule I | SUPAHasECAPolicyRule I
| I | I
skipping to change at page 96, line 48 skipping to change at page 104, line 56
| I | I
| +---------------+-------------+ | +---------------+-------------+
| I I | I I
/ \ I I / \ I I
A I I A I I
C \ / 0..1 I C I C \ / 0..1 I C I
+-----+---------+----------+ +-----------+-----------+ +-----+---------+----------+ +-----------+-----------+
|SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic| |SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic|
+--------------------------+ +-----------------------+ +--------------------------+ +-----------------------+
Figure 25. The Composite Pattern Applied to a SUPAECAPolicyRule Figure 28. The Composite Pattern Applied to a SUPAECAPolicyRule
Note that the HasSUPAECAPolicyRule aggregation is defined by the Note that the HasSUPAECAPolicyRule aggregation is defined by the
HasSUPAECAPolicyRuleDetail association class; both are defined HasSUPAECAPolicyRuleDetail association class; both are defined
in sections 6.6.2 and 6.6.3, respectively. in sections 6.6.2 and 6.6.3, respectively.
6.4.1. SUPAECAPolicyRule Attributes 6.4.1. SUPAECAPolicyRule Attributes
Currently, the SUPAECAPolicyRule defines two attributes, as Currently, the SUPAECAPolicyRule defines two attributes, as
described in the following subsections. described in the following subsections.
6.4.1.1. The Attribute "supaECAPolicyRulePriority" 6.4.1.1. The Attribute "supaECAPolicyRulePriority"
skipping to change at page 97, line 50 skipping to change at page 105, line 53
6.4.2. SUPAECAPolicyRule Relationships 6.4.2. SUPAECAPolicyRule Relationships
Currently, the SUPAECAPolicyRule does not define any Currently, the SUPAECAPolicyRule does not define any
relationships. It inherits all four relationships defined by relationships. It inherits all four relationships defined by
the SUPAPolicyStructure class (see section 5.3.2.). the SUPAPolicyStructure class (see section 5.3.2.).
6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic"
This is a mandatory concrete class. This class is a type of This is a mandatory concrete class. This class is a type of
PolicyContainer, and represents a SUPAECAPolicyRule that can PolicyContainer, and represents a SUPAECAPolicyRule that can
operate as a single, stand-alone, manageable object. Put another operate as a single, stand-alone, manageable object.
way, a SUPAECAPolicyRuleAtomic object can NOT be modeled as a set
of hierarchical SUPAECAPolicyRule objects; if this is required, Put another way, a SUPAECAPolicyRuleAtomic object can NOT be modeled
then a SUPAECAPolicyRuleComposite object should be used instead. as a set of hierarchical SUPAECAPolicyRule objects; if this is
required, then a SUPAECAPolicyRuleComposite object should be
used instead.
6.5.1. SUPAECAPolicyRuleAtomic Attributes 6.5.1. SUPAECAPolicyRuleAtomic Attributes
Currently, the SUPAECAPolicyRuleAtomic class does not define any Currently, the SUPAECAPolicyRuleAtomic class defines a single
attributes. attribute, as described in the following subsection.
6.5.1.1. The Attribute "supaECAPolActionEvalStrategy"
This is a mandatory, non-zero, integer attribute that enumerates
a set of allowable alternatives that define how the set of
SUPAPolicyAction object instances in a SUPAECAPolicyRuleAtomic
object instance are evaluated. It is assumed that the event and
condition clauses of this SUPAECAPolicyRule have evaluated to TRUE.
This attribute controls which SUPAPolicyActions are executed for a
given SUPAPolicyRuleAtomic object instance when it contains multiple
SUPAPolicyActions. Values include:
0: error
1: init
2: execute the first SUPAPolicyAction in the SUPAPolicyRuleAtomic
object and then terminate
3: execute the last SUPAPolicyAction in the SUPAPolicyRuleAtomic
object and then terminate
4: execute only the highest priority SUPAPolicyAction(s) in
the SUPAPolicyRuleAtomic object and then terminate
5: execute all SUPAPolicyActions in prioritized order (if
any) regardless of whether other SUPAPolicyActions
succeed or fail
6: execute all SUPAPolicyActions in prioritized order (if
any) until at least one SUPAPolicyAction fails, and then
terminate
Note that 0 and 1 represent error and initialization states,
respectively. Values 2 and 3 MUST execute a single SUPAPolicyAction,
and then terminate execution of the SUPAECAPolicyRuleAtomic object.
If the value of supaECAPolActionEvalStrategy is 4, 5 or 6, then all
SUPAPolicyActions that have a priority will be executed first,
starting with the SUPAPolicyAction(s) that have the highest
priority, and then descending in prioritized order. During this
process, any SUPAPolicyActions that have the SAME priority MAY be
executed in any order. After all SUPAPolicyActions that have an
associated priority have executed, then all SUPAPolicyAction(s) that
do not have a priority are then executed (in any order).
Assume that the actions in a given SUPAPolicyAction are defined
as follows:
SUPAPolicyAction A, priority 0
SUPAPolicyAction B, priority 10
SUPAPolicyAction C, priority 5
SUPAPolicyAction D, no priority
SUPAPolicyAction E, no priority
Then, if the supaECAPolActionEvalStrategy attribute value equals:
0: an error is issued
1: this SUPAPolicyAction MUST NOT be used (since it is not yet
properly initialized)
2: only SUPAPolicyAction A is executed
3: only SUPAPolicyAction E is executed
4: only SUPAPolicyAction B is executed
5: all SUPAPolicyActions are executed, regardless of any
failures; the order of execution is B, then C, then A, then
one of either D or E, then the other of D or E
6: all SUPAPolicyActions are executed until a failure is
detected, and then execution for all SUPAPolicyActions
terminate; the execution order (up to the occurrence of the
failure) is B, then C, then A, then one of either D or E, then
the other of D or E
6.5.2. SUPAECAPolicyRuleAtomic Relationships 6.5.2. SUPAECAPolicyRuleAtomic Relationships
Currently, the SUPAECAPolicyRuleAtomic class does not define any Currently, the SUPAECAPolicyRuleAtomic class does not define any
relationships. It inherits all four relationships defined by the relationships.
SUPAPolicyStructure class (see section 5.3.2.).
6.6. The Concrete Class "SUPAECAPolicyRuleComposite" 6.6. The Concrete Class "SUPAECAPolicyRuleComposite"
This is a mandatory concrete class. This class is a type of This is a mandatory concrete class. This class is a type of
PolicyContainer, and represents a SUPAECAPolicyRule as a hierarchy PolicyContainer, and represents a SUPAECAPolicyRule as a hierarchy
of SUPAPolicy objects, where the hierarchy contains instances of a of SUPAPolicy objects, where the hierarchy contains instances of a
SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects. SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects.
Each of the SUPAPolicy objects, including the outermost Each of the SUPAPolicy objects, including the outermost
SUPAECAPolicyRuleComposite object, are separately manageable. More SUPAECAPolicyRuleComposite object, are separately manageable. More
importantly, each SUPAECAPolicyRuleComposite object represents an importantly, each SUPAECAPolicyRuleComposite object represents an
aggregated object that is itself manageable. aggregated object that is itself manageable.
The difference between a SUPAECAPolicyRuleComposite and ability
SUPAECAPolicyRuleAtomic is that each SUPAECAPolicyRuleComposite
defines its own scope. This means that all instances of the
SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite classes
will execute according to their priorities. This means that the
priority of the SUPAECAPolicyRuleComposite object is used to
determine the position that its containing SUPAPolicyActions will
be executed; the priorities of the contained SUPAPolicyActions are
then used. Consider the following example:
+--A (SUPAECAPolicyRuleAtomic), priority 5
|
+--B (SUPAECAPolicyRuleAtomic), priority 0
|
+--C (SUPAECAPolicyRuleComposite), priority 10
| |
| +--C1 (SUPAECAPolicyRuleAtomic), priority 2
| |
| +--C2 (SUPAECAPolicyRuleAtomic), priority 1
|
+--D (SUPAECAPolicyRuleAtomic), no priority
The execution order will be C1, followed by C2, followed by A,
followed by B, followed by D.
6.6.1. SUPAECAPolicyRuleComposite Attributes 6.6.1. SUPAECAPolicyRuleComposite Attributes
Currently, the SUPAECAPolicyRuleComposite defines one attribute, Currently, the SUPAECAPolicyRuleComposite class defines one
as described in the following subsection. attribute, as described in the following subsection.
6.6.1.1. The Attribute "supaECAEvalStrategy" 6.6.1.1. The Attribute "supaECAEvalRuleStrategy"
This is a mandatory, non-zero, integer attribute that enumerates This is a mandatory, non-zero, integer attribute that enumerates
a set of allowable alternatives that define how the set of a set of allowable alternatives that define how the set of
SUPAECAPolicyRule object instances in a SUPAECAPolicyRuleComposite SUPAPolicyAction object instances in a SUPAECAPolicyRuleComposite
object are evaluated. It is assumed that the event and condition object are evaluated. It is assumed that the event and condition
clauses of the SUPAECAPolicyRules have evaluated to TRUE (e.g., the clauses of the SUPAECAPolicyRuleComposite have evaluated to TRUE
event has occurred and the conditions were met). Values include: (e.g., the event has occurred and the conditions were met).
Values include:
0: error 0: error
1: init 1: init
2: execute the first SUPAECAPolicyRule in the 2: execute the first SUPAPolicyAction in the
SUPAECAPolicyRuleComposite and then terminate SUPAECAPolicyRuleComposite object and then terminate
3: execute only the highest priority SUPAECAPolicyRule(s) in 3: execute the last SUPAPolicyAction in the
the SUPAECAPolicyRuleComposite and then terminate SUPAECAPolicyRuleComposite object and then terminate
4: execute all SUPAECAPolicyRules in prioritized order (if 4: execute only the highest priority SUPAPolicyAction(s) in
any) regardless of whether their SUPAPolicyActions the SUPAECAPolicyRuleComposite object and then terminate
succeed or fail 5: execute all SUPAPolicyActions in prioritized order (if
5: execute all SUPAECAPolicyRules in prioritized order (if any) in that particular SUPAECAPolicyRuleComposite object,
any) until at least one SUPAPolicyAction in a regardless of whether other SUPAPolicyActions succeed or fail
SUPAECAPolicyRule fails, and then terminate 6: execute all SUPAPolicyActions in prioritized order (if
any) in that particular SUPAECAPolicyRuleComposite object
until at least one SUPAPolicyAction fails, and then terminate
Note that 0 and 1 represent error and initialization states, Note that 0 and 1 represent error and initialization states,
respectively. respectively. Values 2 and 3 MUST execute a single SUPAPolicyAction,
and then terminate execution of all SUPAPolicyActions in this
SUPAECAPolicyRuleComposite object.
If the value of supaECAEvalStrategy is 3 or 4, then all If the value of the supaECAEvalStrategy attribute is 4, 5 or 6, then
SUPAECAPolicyRules that have a priority will be executed first all SUPAPolicyActions that have a priority will be executed first,
(starting with the SUPAECAPolicyRule(s) that have the highest starting with the SUPAPolicyAction(s) that have the highest
priority, and descending); all SUPAECAPolicyRule(s) that do not priority, and then descending in prioritized order. During this
have a priority are then executed (in any order). process, any SUPAPolicyActions that have the SAME priority MAY be
executed in any order. After all SUPAPolicyActions that have an
associated priority have executed, then all SUPAPolicyAction(s) that
do not have a priority are then executed (in any order).
Assume that the actions in a given SUPAECAPolicyRuleComposite Assume that a SUPAECAPolicyRuleComposite object contains three
are defined as follows SUPAECAPolicyRuleAtomic objects as well as one
SUPAECAPolicyRuleComposite object (that contains two
SUPAECAPolicyRuleAtomic objects), as shown below.
SUPAECAPolicyRule A, priority 0 Z (SUPAECAPolicyRuleComposite)
SUPAECAPolicyRule B, priority 10 |
SUPAECAPolicyRule C, priority 5 +--A (SUPAECAPolicyRuleAtomic), priority 5
SUPAECAPolicyRule D, priority 10 |
SUPAECAPolicyRule E, priority 2 +--B (SUPAECAPolicyRuleAtomic), priority 0
|
+--C (SUPAECAPolicyRuleComposite), priority 10
| |
| +--C1 (SUPAECAPolicyRuleAtomic), priority 2
| |
| +--C2 (SUPAECAPolicyRuleAtomic), priority 1
|
+--D (SUPAECAPolicyRuleAtomic), no priority
Then, if the supaECAEvalStrategy attribute value equals: Then, if the supaECAEvalStrategy attribute value of Z equals:
0: an error is issued 0: an error is issued
1: this SUPAECAPolicyRule MUST NOT be used (since it is not yet 1: all SUPAPolicyActions MUST NOT be used (since their containing
properly initialized) SUPAECAPolicyRuleComposite object is not properly initialized)
2: only SUPAECAPolicyRule A is executed 2: only SUPAPolicyAction A is executed
3: only SUPAECAPolicyRules B and D are executed 3: only SUPAPolicyAction D is executed
4: all SUPAECAPolicyRules are executed, regardless of any 4: two SUPAPolicyActions are executed: C1, followed by C2
failures in their SUPAPolicyActions 5: all SUPAPolicyActions are executed, regardless of any
5: all SUPAECAPolicyRules are executed until a failure is failures; the order of execution is C1, then C2, then A, then
detected, and then execution for all SUPAECAPolicyRules B, then D
terminates 6: all SUPAPolicyActions are executed until a failure is
detected, and then execution for all SUPAPolicyActions
terminate; the execution order (up to the occurrence of the
failure) is C1, then C2, then A, then B, then D
Note that the supaECAEvalRuleStrategy defines the same semantics as
the supaECAPolActionEvalStrategy. The difference is that the former
is applied to a SUPAECAPolicyRuleComposite object, and the latter is
applied to a SUPAECAPolicyRuleAtomic object.
6.6.2. SUPAECAPolicyRuleComposite Relationships 6.6.2. SUPAECAPolicyRuleComposite Relationships
Currently, the SUPAECAPolicyRuleComposite defines a single Currently, the SUPAECAPolicyRuleComposite defines a single
aggregation between it and SUPAECAPolicyRule, as described below. aggregation between it and SUPAECAPolicyRule, as described below.
6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule"
This is an optional aggregation that implements the composite This is an optional aggregation that implements the composite
pattern. The multiplicity of this aggregation is 0..1 on the pattern. The multiplicity of this aggregation is 0..1 on the
aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part
(SUPAECAPolicyRule) side. This means that if this aggregation (SUPAECAPolicyRule) side. This means that if this aggregation
is defined, then at least one SUPAECAPolicyRule object (which may is defined, then at least one SUPAECAPolicyRule object (which may
be either an instance of a SUPAECAPolicyRuleAtomic or a be either an instance of a SUPAECAPolicyRuleAtomic or a
SUPAECAPolicyRuleComposite class) must also be instantiated and SUPAECAPolicyRuleComposite class) must also be instantiated and
aggregated by this particular SUPAECAPolicyRuleComposite object. aggregated by this particular SUPAECAPolicyRuleComposite object.
The semantics of this aggregation are defined by the The semantics of this aggregation are defined by the
SUPAHasECAPolicyRuleDetail association class. SUPAHasECAPolicyRuleDetail association class.
6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" 6.6.2.2. The Association Class "SUPAHasECAPolicyRuleDetail"
This is an optional concrete association class, and defines the This is an optional concrete association class, and defines the
semantics of the SUPHasECAPolicyRule aggregation. This enables the semantics of the SUPHasECAPolicyRule aggregation. This enables the
attributes and relationships of the SUPAHasECAPolicyRuleDetail attributes and relationships of the SUPAHasECAPolicyRuleDetail
class to be used to constrain which SUPHasECAPolicyRule objects class to be used to constrain which SUPAECAPolicyRule objects
can be aggregated by this particular SUPAECAPolicyRuleComposite can be aggregated by this particular SUPAECAPolicyRuleComposite
object instance. object instance. It contains a single attribute, defined below.
6.6.3.1. The Attribute "supaECAPolicyIsDefault" 6.6.2.2.1. The Attribute "supaECAPolicyIsDefault"
This is an optional Boolean attribute. If the value of this This is an optional Boolean attribute. If the value of this
attribute is true, then this SUPAECAPolicyRule is a default attribute is true, then this SUPAECAPolicyRule is a default
policy, and will be executed if no other SUPAECAPolicyRule policy, and will be executed if no other SUPAECAPolicyRule
in the SUPAECAPolicyRuleComposite container has been executed. in the SUPAECAPolicyRuleComposite container has been executed.
This is a convenient way for error handling, though care should This is a convenient way for error handling, though care should
be taken to ensure that only one default policy rule is defined be taken to ensure that only one default policy rule is defined
per SUPAECAPolicyRuleComposite container. per SUPAECAPolicyRuleComposite container.
6.7. The Abstract Class "SUPABooleanClause" 6.7. The Abstract Class "SUPABooleanClause"
skipping to change at page 100, line 55 skipping to change at page 110, line 22
the SUPA object hierarchy. the SUPA object hierarchy.
An entire SUPABooleanClause may be negated by setting the An entire SUPABooleanClause may be negated by setting the
supaBoolClauseIsNegated class attribute of the SUPABooleanClause supaBoolClauseIsNegated class attribute of the SUPABooleanClause
class to TRUE. Individual terms of a Boolean clause can be negated class to TRUE. Individual terms of a Boolean clause can be negated
by using the supaTermIsNegated Boolean attribute in the by using the supaTermIsNegated Boolean attribute in the
SUPAPolicyTerm class (see section 5.10). SUPAPolicyTerm class (see section 5.10).
A PolicyClause is in Conjunctive Normal Form (CNF) if it is a A PolicyClause is in Conjunctive Normal Form (CNF) if it is a
sequence of logically ANDed terms, where each term is a sequence sequence of logically ANDed terms, where each term is a sequence
of logically ORed terms. of logically ORed terms. A PolicyClause is in Disjunctive Normal
Form (DNF) if it is a sequence of logically ORed terms, where each
A PolicyClause is in Disjunctive Normal Form (DNF) if it is a term is a sequence of logically ANDed terms.
sequence of logically ORed terms, where each term is a sequence
of logically ANDed terms.
The construction of more complex clauses, which consist of a set The construction of more complex clauses, which consist of a set
of simple clauses in CNF or DNF (as shown in the above example), of simple clauses in CNF or DNF (as shown in the above example),
is provided by using the composite pattern [3] to construct two is provided by using the composite pattern [3] to construct two
concrete subclasses of the abstract SUPABooleanClause class. These concrete subclasses of the abstract SUPABooleanClause class. These
are called SUPABooleanClauseAtomic and SUPABooleanClauseComposite, are called SUPABooleanClauseAtomic and SUPABooleanClauseComposite,
and are defined in sections 6.8 and 6.9, respectively. This and are defined in sections 6.8 and 6.9, respectively. This
enables instances of either a SUPABooleanClauseAtomic and/or a enables instances of either a SUPABooleanClauseAtomic and/or a
SUPABooleanClauseComposite to be aggregated into a SUPABooleanClauseComposite to be aggregated into a
SUPABooleanClauseComposite object. SUPABooleanClauseComposite object.
6.7.1. SUPABooleanClause Attributes 6.7.1. SUPABooleanClause Attributes
The SUPABooleanClause class currently defines one attribute, The SUPABooleanClause class currently defines three attributes,
which are defined in the following subsections. which are defined in the following subsections.
6.7.1.1. The Attribute "supaBoolClauseIsNegated" 6.7.1.1. The Attribute "supaBoolClauseBindValue"
This is a mandatory non-zero integer attribute, and defines the
order in which terms bind to a clause. For example, the Boolean
expression "((A AND B) OR (C AND NOT (D OR E)))" has the following
binding order: terms A and B have a bind value of 1; term C has a
binding value of 2, and terms D and E have a binding value of 3.
6.7.1.2. The Attribute "supaBoolClauseIsCNF"
This is an optional Boolean attribute. If the value of this
attribute is TRUE, then this SUPABooleanClauseComposite is in CNF
form. Otherwise, it is in DNF form.
6.7.1.3. The Attribute "supaBoolClauseIsNegated"
This is a mandatory Boolean attribute. If the value of this This is a mandatory Boolean attribute. If the value of this
attribute is TRUE, then this (entire) SUPABooleanClause is attribute is TRUE, then this (entire) SUPABooleanClause is
negated. Note that the supaPolTermIsNegated class attribute of negated. Note that the supaPolTermIsNegated class attribute of
the SUPAPolicyTerm class is used to negate a single term. the SUPAPolicyTerm class is used to negate a single term.
6.7.2. SUPABooleanClause Relationships 6.7.2. SUPABooleanClause Relationships
Currently, no relationships are defined for the SUPABooleanClause Currently, no relationships are defined for this class.
class. It inherits the relationships of SUPAPolicyClause (see
section 5.5.).
6.8. The Concrete Class "SUPABooleanClauseAtomic" 6.8. The Concrete Class "SUPABooleanClauseAtomic"
This is a mandatory concrete class that represents a This is a mandatory concrete class that represents a
SUPABooleanClause that can operate as a single, stand-alone, SUPABooleanClause that can operate as a single, stand-alone,
manageable object. A SUPABooleanClauseAtomic object can NOT be manageable object. A SUPABooleanClauseAtomic object can NOT be
modeled as a set of hierarchical clauses; if this functionality is modeled as a set of hierarchical clauses; if this functionality is
required, then a SUPABooleanClauseComposite object must be used. required, then a SUPABooleanClauseComposite object must be used.
Examples of Boolean clauses that could be contained in a Examples of Boolean clauses that could be contained in a
SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P
and Q are literals (e.g., a variable name that can be either true and Q are literals (e.g., a variable name that can be either true
or false, or a formula that evaluates to a literal). Examples of or false, or a formula that evaluates to a literal). Examples of
Boolean clauses that are NOT in CNF are NOT(P AND Q), Boolean clauses that are NOT in CNF are NOT(P AND Q),
(P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent (P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent
forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and
P AND (Q OR S) AND (Q OR S), respectively. P AND (Q OR S) AND (Q OR S), respectively.
6.8.1. SUPABooleanClauseAtomic Attributes 6.8.1. SUPABooleanClauseAtomic Attributes
No attributes are currently defined for the No attributes are currently defined for this class.
SUPABooleanClauseAtomic class.
6.8.2. SUPABooleanClauseAtomic Relationships 6.8.2. SUPABooleanClauseAtomic Relationships
Currently, no relationships are defined for the Currently, no relationships are defined for this class.
SUPABooleanClauseAtomic class. It inherits the relationships of
SUPAPolicyClause (see section 5.5.).
6.9. The Concrete Class "SUPABooleanClauseComposite" 6.9. The Concrete Class "SUPABooleanClauseComposite"
This is a mandatory concrete class that represents a This is a mandatory concrete class that represents a
SUPABooleanClause that can operate as a hierarchy of PolicyClause SUPABooleanClause that can operate as a hierarchy of
objects, where the hierarchy contains instances of SUPAPolicyClause objects, where the hierarchy contains instances of
SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite
objects. Each of the SUPABooleanClauseAtomic and objects. Each of the SUPABooleanClauseAtomic and
SUPABooleanClauseComposite objects, including the outermost SUPABooleanClauseComposite objects, including the outermost
SUPABooleanClauseComposite object, are separately manageable. SUPABooleanClauseComposite object, are separately manageable.
More importantly, each SUPABooleanClauseComposite object
More importantly, each SUPAECAPolicyRuleComposite object
represents an aggregated object that is itself manageable. represents an aggregated object that is itself manageable.
Examples of Boolean clauses that could be contained in a Examples of Boolean clauses that could be contained in a
SUPABooleanClauseAtomic include ((P OR Q) AND R), and SUPABooleanClauseComposite object include ((P OR Q) AND R), and
((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, and ((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, and
T are literals. T are literals.
6.9.1. SUPABooleanClauseComposite Attributes 6.9.1. SUPABooleanClauseComposite Attributes
Two attributes are currently defined for the No attributes are currently defined for this class.
SUPABooleanClauseComposite class, and are described in the
following subsections.
6.9.1.1. The Attribute "supaBoolClauseBindValue"
This is a mandatory non-zero integer attribute, and defines the
order in which terms bind to a clause. For example, the Boolean
expression "((A AND B) OR (C AND NOT (D OR E)))" has the following
binding order: terms A and B have a bind value of 1; term C has a
binding value of 2, and terms D and E have a binding value of 3.
6.9.1.2. The Attribute "supaBoolClauseIsCNF"
This is an optional Boolean attribute. If the value of this
attribute is TRUE, then this SUPABooleanClauseComposite is in CNF
form. Otherwise, it is in DNF form.
6.9.2. SUPABooleanClauseComposite Relationships 6.9.2. SUPABooleanClauseComposite Relationships
Currently, the SUPABooleanClauseComposite class defined a single Currently, the SUPABooleanClauseComposite class defines a single
aggregation, which is described in the subsections below. aggregation, which is described in the following subsection.
6.9.2.1. The Aggregation "SUPAHasBooleanClause" 6.9.2.1. The Aggregation "SUPAHasBooleanClause"
This is a mandatory aggregation that defines the set of This is a mandatory aggregation that defines the set of
SUPABooleanClause objects that are aggregated by this SUPABooleanClause objects that are aggregated by this
SUPABooleanClauseComposite object. SUPABooleanClauseComposite object.
The multiplicity of this relationship is 0..1 on the aggregate The multiplicity of this relationship is 0..1 on the aggregate
(SUPABooleanClauseComposite) side, and 1..n on the part (SUPABooleanClauseComposite) side, and 1..n on the part
(SUPABooleanClause) side. This means that one or more (SUPABooleanClause) side. This means that one or more
SUPABooleanClauses are aggregated and used to define this SUPABooleanClauses are aggregated and used to define this
SUPABooleanClauseComposite object. The 0..1 cardinality on the SUPABooleanClauseComposite object. The 0..1 cardinality on the
SUPABooleanClauseComposite side is necessary to enable SUPABooleanClauseComposite side is necessary to enable
SUPABooleanClauses to exist (e.g., in a PolicyRepository) before SUPABooleanClauses to exist (e.g., in a PolicyRepository) before
they are used by a SUPABooleanClauseComposite. The semantics of they are used by a SUPABooleanClauseComposite. The semantics of
this aggregation is defined by the SUPAHasBooleanClauseDetail this aggregation is defined by the SUPAHasBooleanClauseDetail
association class. association class.
6.9.3. The Association Class "SUPAHasBooleanClauseDetail" 6.9.2.2. The Association Class "SUPAHasBooleanClauseDetail"
This is a mandatory concrete association class that defines the This is a mandatory concrete association class that defines the
semantics of the SUPAHasBooleanClause aggregation. This enables the semantics of the SUPAHasBooleanClause aggregation. This enables the
attributes and relationships of the SUPAHasBooleanClauseDetail attributes and relationships of the SUPAHasBooleanClauseDetail
class to be used to constrain which SUPABooleanClause objects class to be used to constrain which SUPABooleanClause objects
can be aggregated by this particular SUPABooleanClauseComposite can be aggregated by this particular SUPABooleanClauseComposite
object instance. object instance.
6.9.3.1. SUPAHasBooleanClauseDetail Attributes 6.9.2.2.1. The Attribute "supaIsHornClause"
The SUPAHasBooleanClauseDetail class currently does not define This is an optional attribute of type Boolean. If the value of this
any attributes. attribute is TRUE, then this SUPABooleanClause is a Horn clause.
This has important properties for logic programming and model
theory. For example, a Horn clause is able to express implication
of one variable from a set of other variables.
6.10. The Abstract Class "SUPAECAComponent" 6.10. The Abstract Class "SUPAECAComponent"
This is a mandatory abstract class that defines three concrete This is a mandatory abstract class that defines three concrete
subclasses, one each to represent the concepts of reusable events, subclasses, one each to represent the concepts of reusable events,
conditions, and actions. They are called SUPAPolicyEvent, conditions, and actions. They are called SUPAPolicyEvent,
SUPAPolicyCondition, and SUPAPolicyAction, respectively. SUPAPolicyCondition, and SUPAPolicyAction, respectively.
SUPAECAComponents provide two different ways to construct SUPAECAComponents provide two different ways to construct
SUPAPolicyClauses. The first is for the SUPAECAComponent to be SUPAPolicyClauses. The first is for the SUPAECAComponent to be
used as either a SUPAPolicyVariable or a SUPAPolicyValue, and the used as either a SUPAPolicyVariable or a SUPAPolicyValue, and the
second is for the SUPAECAComponent to contain the entire clause second is for the SUPAECAComponent to contain the entire clause
text. text.
For example, suppose it is desired to define a policy condition For example, suppose it is desired to define a policy condition
clause with the text 'queueDepth > 10'. The two approaches could clause with the text 'queueDepth > 10'. Two approaches could
satisfy this as follows: satisfy this as follows:
Approach #1 (canonical form): Approach #1 (canonical form):
SUPAPolicyCondition.supaPolicyConditionData contains the text SUPAPolicyCondition.supaPolicyConditionData contains the text
'queueDepth' 'queueDepth'
SUPAPolicyOperator.supaPolOpType is set to '1' (greater than) SUPAPolicyOperator.supaPolOpType is set to '1' (greater than)
SUPAPolicyValue.supaPolValContent is set to '10' SUPAPolicyValue.supaPolValContent is set to '10'
Approach #2 (SUPAECAComponent represents the entire clause): Approach #2 (SUPAECAComponent represents the entire clause):
SUPAPolicyCondition.supaPolicyConditionData contains the text SUPAPolicyCondition.supaPolicyConditionData contains the text
skipping to change at page 104, line 24 skipping to change at page 113, line 41
The class attribute supaECACompIsTerm, defined in subsection The class attribute supaECACompIsTerm, defined in subsection
6.10.1.1, is used to identify which of these two approaches is 6.10.1.1, is used to identify which of these two approaches is
used by an object instance of this class. used by an object instance of this class.
6.10.1. SUPAECAComponent Attributes 6.10.1. SUPAECAComponent Attributes
A single attribute is currently defined for this class, and is A single attribute is currently defined for this class, and is
described in the following subsection. described in the following subsection.
6.10.1.1. The Attribute supaECACompIsTerm 6.10.1.1. The Attribute "supaECACompIsTerm"
This is an optional Boolean attribute. If the value of this This is an optional Boolean attribute. If the value of this
attribute is TRUE, then this SUPAECAComponent is used as the value attribute is TRUE, then this SUPAECAComponent is used as the value
of a SUPAPolicyTerm to construct a SUPAPolicyClause (this is of a SUPAPolicyTerm to construct a SUPAPolicyClause (this is
approach #1 in section 6.10 above). If the value of this attribute approach #1 in section 6.10 above). If the value of this attribute
is FALSE, then this SUPAECAComponent contains the text of the is FALSE, then this SUPAECAComponent contains the text of the
entire corresponding SUPAPolicyClause (this is approach #2 in entire corresponding SUPAPolicyClause (this is approach #2 in
section 6.10 above). section 6.10 above).
6.10.2. SUPAECAComponent Relationships 6.10.2. SUPAECAComponent Relationships
No relationships are currently defined for this class. No relationships are currently defined for this class.
6.11. The Concrete Class "SUPAPolicyEvent" 6.11. The Concrete Class "SUPAPolicyEvent"
This is a mandatory concrete class that represents the concept of This is a mandatory concrete class that represents the concept of
an Event that is applicable to a policy management system. Such an Event that is applicable to a policy management system. Such
an Event is defined as anything of importance to the management an Event is defined as anything of importance to the management
system (e.g., a change in the system being managed and/or its system (e.g., a change in the system being managed and/or its
environment) occuring on a time-axis (as defined in [19]). environment) occuring on a time-axis (as defined in [19]).
It should be noted that instances of this class are not themselves
events. Rather, instances of this class appear in SUPAPolicyClauses
to describe what types of events the SUPAPolicy is triggered by
and/or uses.
SUPAPolicyEvents can be used as part of a SUPAPolicyClause; this SUPAPolicyEvents can be used as part of a SUPAPolicyClause; this
is done by specifying the attribute name and value of an Event in is done by specifying the attribute name and value of an Event in
the supaPolicyEventData attribute of the SUPAPolicyEvent. This the supaPolicyEventData attribute of the SUPAPolicyEvent. This
enables event attributes to be used as part of a SUPAPolicyClause. enables event attributes to be used as part of a SUPAPolicyClause.
Note: this class does NOT model the "raw" occurrences of Events. Information from events that trigger SUPAPolicies need to be made
Rather, it represents the concept of an Event object whose class available for use in condition and action clauses, as well as
attributes describe pertinent attributes that can trigger the inappropriate decorator objects. Subclasses (such as one for using
evaluation of a SUPAECAPolicyRule. YANG notifications as policy events) need to define how the
iformation from the environment or event is used to populate
variables that can be used by decorator, condition, or
action objects.
6.11.1. SUPAPolicyEvent Attributes 6.11.1. SUPAPolicyEvent Attributes
Currently, five attributes are defined for the SUPAPolicyEvent Currently, five attributes are defined for the SUPAPolicyEvent
class, which are described in the following subsections. class, which are described in the following subsections.
6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 6.11.1.1. The Attribute "supaPolicyEventData[1..n]"
This is an optional Boolean attribute. If the value of this This is a mandatory attribute that defines an array of strings.
attribute is TRUE, then this SUPAPolicyEvent has been pre- Each string in the array represents an attribute name and value
processed by an external entity, such as an Event Service Bus, of an Event object. The format of each string is defined as
before it was received by the Policy Management System. name:value. The 'name' part is the name of the SUPAPolicyEvent
attribute, and the 'value' part is the value of that attribute.
6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" Note: [1..n] means that this is a multi-valued property that has
at least one (and possibly more) attributes. For example, if
this value of this attribute is:
This is an optional Boolean attribute. If the value of this {(startTime:0800), (endTime:1700), (date:2016-05-11),
attribute is TRUE, then this SUPAPolicyEvent has been produced by (timeZone:-08:00)}
the Policy Management System. If the value of this attribute is
FALSE, then this SUPAPolicyEvent has been produced by an entity
in the system being managed.
6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" then this attribute contains four properties, called startTime,
endTime, date, and timeZone, whose values are 0800, 1700, May 11
2016, and Pacific Standard Time, respectively.
This is a mandatory array of string attributes, and contains the This attribute works with another class attribute, called
subject that this PolicyEvent describes. supaPolicyEventEncoding, which defines how to interpret this
Note: [0..n] means that this is a multi-valued property that has attribute. These two attributes form a tuple, and together enable
zero or more attributes. a machine to understand the syntax and value of the data carried
by the object instance of this class.
6.11.1.4. The Attribute "supaPolicyEventEncoding" 6.11.1.2. The Attribute "supaPolicyEventEncoding"
This is a mandatory non-zero enumerated integer attribute, and This is a mandatory non-zero enumerated integer attribute, and
defines how to interpret the supaPolicyEventData class attribute. defines how to interpret the supaPolicyEventData class attribute.
These two attributes form a tuple, and together enable a machine These two attributes form a tuple, and together enable a machine
to understand the syntax and value of the data carried by the to understand the syntax and value of the data carried by the
object instance of this class. Values include: object instance of this class. Values include:
0: error 0: error
1: init 1: init
2: String 2: String
3: Integer 3: Integer
4: Boolean 4: Boolean
5: Floating Point 5: Floating Point
6: DateTime 6: DateTime
7: Object referenced by GUID
8: Object referenced by URI
9: Object referenced by FQDN
10: Object referenced by FQPN
11: Object referenced by string_instance_id
6.11.1.5. The Attribute "supaPolicyEventData[1..n]" Enumerations 0 and 1 signify an error state and an initialization
state, respectively. Enumerations 2-6 define fundamental data types;
for example, the event payload could carry such a value. The final
five enumerations define an object reference. The value 11 defines
the canonical representation, in ASCII, of an instance ID of
this object.
This is a mandatory attribute that defines an array of strings. 6.11.1.3. The Attribute "supaPolicyEventIsPreProcessed"
Each string in the array represents an attribute name and value
of an Event object. The format of each string is defined as
name:value. The 'name' part is the name of the SUPAPolicyEvent
attribute, and the 'value' part is the value of that attribute.
Note: [1..n] means that this is a multi-valued property that has This is an optional Boolean attribute. If the value of this
at least one (and possibly more) attributes. For example, if attribute is TRUE, then this SUPAPolicyEvent has been pre-
this value of this attribute is: processed by an external entity, such as an Event Service Bus,
before it was received by the Policy Management System.
{(startTime:0800), (endTime:1700), (date:2016-05-11), 6.11.1.4. The Attribute "supaPolicyEventIsSynthetic"
(timeZone:-08:00)}
then this attribute contains four properties, called startTime, This is an optional Boolean attribute. If the value of this
endTime, date, and timeZone whose values are 0800, 1700, May 11 attribute is TRUE, then this SUPAPolicyEvent has been produced by
2016, and Pacific Standard Time, respectively. the Policy Management System. If the value of this attribute is
FALSE, then this SUPAPolicyEvent has been produced by an entity
in the system being managed.
Note that the supaPolicyEventEncoding class attribute defines how 6.11.1.5. The Attribute "supaPolicyEventTopic[0..n]"
to interpret the value portion of this attribute.
This attribute works with another class attribute, called This is a mandatory array of string attributes, and contains the
supaPolicyEventEncoding, which defines how to interpret this subject that this PolicyEvent describes.
attribute. These two attributes form a tuple, and together enable
a machine to understand the syntax and value of the data carried Note: [0..n] means that this is a multi-valued property that has
by the object instance of this class. zero or more attributes.
6.11.2. SUPAPolicyEvent Relationships 6.11.2. SUPAPolicyEvent Relationships
No relationships are currently defined for this class. It inherits No relationships are currently defined for this class.
the relationships defined by the SUPAPolicyComponentDecorator (see
section 5.7.3.).
6.12. The Concrete Class "SUPAPolicyCondition" 6.12. The Concrete Class "SUPAPolicyCondition"
This is a mandatory concrete class that represents the concept of This is a mandatory concrete class that represents the concept of
an Condition that will determine whether or not the set of Actions an Condition that will determine whether or not the set of Actions
in the SUPAECAPolicyRule to which it belongs are executed or not. in the SUPAECAPolicyRule to which it belongs are executed or not.
Condition clauses needs to be able to access information fromhe
the policy environment (e.g., the network element or policy engine
applying the policy) or the triggering event. This may be done
using SUPAPolicyVariable objects as decorators. If the subclass of
a SUPAPolicyCondition uses some other encoding, the definition of
that class needs to indicate how information from the environment
or event will be used.
SUPAPolicyConditions can be used as part of a SUPAPolicyClause SUPAPolicyConditions can be used as part of a SUPAPolicyClause
(e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or as a (e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or as a
stand-alone SUPAPolicyClause (e.g., the supaPolicyConditionData standalone SUPAPolicyClause (e.g., the supaPolicyConditionData
attribute contains text that defines the entire condition clause). attribute contains text that defines the entire condition clause).
This is defined in the supaECACompIsTerm attribute of the
SUPAECAComponent class (see section 6.10).
6.12.1. SUPAPolicyCondition Attributes 6.12.1. SUPAPolicyCondition Attributes
Currently, two attributes are defined for the SUPAPolicyCondition Currently, two attributes are defined for the SUPAPolicyCondition
class, which are described in the following subsections. class, which are described in the following subsections.
6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]"
This is a mandatory array of string attributes that contains the This is a mandatory array of string attributes that contains the
content of this SUPAPolicyCondition object. content of this SUPAPolicyCondition object.
skipping to change at page 106, line 50 skipping to change at page 116, line 47
6.12.1. SUPAPolicyCondition Attributes 6.12.1. SUPAPolicyCondition Attributes
Currently, two attributes are defined for the SUPAPolicyCondition Currently, two attributes are defined for the SUPAPolicyCondition
class, which are described in the following subsections. class, which are described in the following subsections.
6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]"
This is a mandatory array of string attributes that contains the This is a mandatory array of string attributes that contains the
content of this SUPAPolicyCondition object. content of this SUPAPolicyCondition object.
Note: [1..n] means that this is a multi-valued property that has Note: [1..n] means that this is a multi-valued property that has
at least one (and possibly more) attributes. at least one (and possibly more) attributes.
This attribute works with another class attribute, called If this class is instantiated, then this attribute SHOULD also be
supaPolicyConditionEncoding, which defines how to interpret this instantiated, and SHOULD be part of a conformant implementation.
attribute. These two attributes form a tuple, and together enable
a machine to understand the syntax and value of the data carried
by the object instance of this class.
6.12.1.2. The Attribute "supaPolicyConditionEncoding" 6.12.1.2. The Attribute "supaPolicyConditionEncoding"
This is a mandatory non-zero enumerated integer attribute, and This is a mandatory non-zero enumerated integer attribute, and
defines the data type of the supaPolicyConditionData attribute. defines the data type of the supaPolicyConditionData attribute.
These two attributes form a tuple, and together enable a machine These two attributes form a tuple, and together enable a machine
to understand the syntax and value of the content of this to understand the syntax and value of the content of this