draft-ietf-supa-generic-policy-info-model-00.txt   draft-ietf-supa-generic-policy-info-model-01.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: December 21, 2016 Ericsson Expires: January 19, 2017 S. van der Meer
June 21, 2016 Ericsson
July 19, 2016
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-00 draft-ietf-supa-generic-policy-info-model-01
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 35 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 December 21, 2016. This Internet-Draft will expire on January 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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
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
3.2.1.2. Data Model ..................................... 13 3.2.1.2. Data Model ..................................... 13
3.2.1.3. Abstract Class ................................. 13 3.2.1.3. Class .......................................... 13
3.2.1.4. Concrete Class ................................. 13 3.2.1.3.1. Abstract Class ............................... 13
3.2.1.5. Container ...................................... 13 3.2.1.3.2. Concrete Class ............................... 13
3.2.1.6. PolicyContainer ................................ 13 3.2.1.4. Container ...................................... 13
3.2.2. Policy Terminology ................................... 14 3.2.1.5. PolicyContainer ................................ 13
3.2.2. Policy Terminology .................................. 14
3.2.2.1. SUPAPolicyObject ............................... 14 3.2.2.1. SUPAPolicyObject ............................... 14
3.2.2.2. SUPAPolicy ..................................... 14 3.2.2.2. SUPAPolicy ..................................... 14
3.2.2.3. SUPAPolicyClause ............................... 14 3.2.2.3. SUPAPolicyClause ............................... 14
3.2.2.4. SUPAECAPolicyRule .............................. 14 3.2.2.4. SUPAECAPolicyRule .............................. 15
3.2.2.5. SUPAMetadata ................................... 15 3.2.2.5. SUPAMetadata ................................... 15
3.2.2.6. SUPAPolicyTarget ............................... 15 3.2.2.6. SUPAPolicyTarget ............................... 15
3.2.2.7. SUPAPolicySource ............................... 15 3.2.2.7. SUPAPolicySource ............................... 15
3.2.3. Modeling Terminology ................................. 16 3.2.3. Modeling Terminology ................................ 16
3.2.3.1. Inheritance .................................... 16 3.2.3.1. Inheritance .................................... 16
3.2.3.2. Relationship ................................... 16 3.2.3.2. Relationship ................................... 16
3.2.3.3. Association .................................... 16 3.2.3.3. Association .................................... 17
3.2.3.4. Aggregation .................................... 16 3.2.3.4. Aggregation .................................... 17
3.2.3.5. Composition .................................... 17 3.2.3.5. Composition .................................... 17
3.2.3.6. Association Class .............................. 17 3.2.3.6. Association Class .............................. 17
3.2.3.7. Multiplicity ................................... 17 3.2.3.7. Multiplicity ................................... 18
3.2.3.8. Navigability ................................... 17 3.2.3.8. Navigability ................................... 18
3.3. Symbology ................................................ 18 3.3. Symbology ................................................ 18
3.3.1. Inheritance ......................................... 18 3.3.1. Inheritance ......................................... 18
3.3.2. Association ......................................... 18 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
Table of Contents (continued) Table of Contents (continued)
skipping to change at page 3, line 33 skipping to change at page 3, line 33
4.4.7.1. Motivation ..................................... 39 4.4.7.1. Motivation ..................................... 39
4.4.7.2. Design Approach ................................ 40 4.4.7.2. Design Approach ................................ 40
4.4.7.2.1. Policies and Actors ....................... 42 4.4.7.2.1. Policies and Actors ....................... 42
4.4.7.2.2. Deployment vs. Execution of Policies ...... 43 4.4.7.2.2. Deployment vs. Execution of Policies ...... 43
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 ............................. 43
4.4.7.3. Structure of SUPAPolicyMetadata ................ 44 4.4.7.3. Structure of SUPAPolicyMetadata ................ 44
4.5. Advanced Features ........................................ 47 4.5. Advanced Features ........................................ 47
4.5.1. Policy Grouping ..................................... 47 4.5.1. Policy Grouping ..................................... 47
4.5.2. Policy Rule Nesting ................................. 47 4.5.2. Policy Rule Nesting ................................. 47
5. GPIM Model ..................................................... 48 5. GPIM Model .................................................... 48
5.1. Overview .................................................. 48 5.1. Overview ................................................. 48
5.2. The Abstract Class "SUPAPolicyObject" ..................... 49 5.2. The Abstract Class "SUPAPolicyObject" .................... 49
5.2.1. SUPAPolicyObject Attributes .......................... 50 5.2.1. SUPAPolicyObject Attributes ......................... 50
5.2.1.1. Object Identifiers ............................. 50 5.2.1.1. Object Identifiers ............................. 50
5.2.1.2. The Attribute "supaPolObjIDContent" ............. 51 5.2.1.2. The Attribute "supaPolObjIDContent" ............ 51
5.2.1.3. The Attribute "supaPolObjIDEncoding" ............ 51 5.2.1.3. The Attribute "supaPolObjIDEncoding" ........... 51
5.2.1.4. The Attribute "supaPolicyDescription" ........... 51 5.2.1.4. The Attribute "supaPolicyDescription" .......... 51
5.2.1.5. The Attribute "supaPolicyName" .................. 51 5.2.1.5. The Attribute "supaPolicyName" ................. 51
5.2.2. SUPAPolicy Relationships ............................ 52 5.2.2. SUPAPolicy Relationships ............................ 52
5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 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" .................. 52
5.3. The Abstract Class "SUPAPolicyStructure" ................. 52 5.3. The Abstract Class "SUPAPolicyStructure" ................. 52
5.3.1. SUPAPolicyStructure Attributes ...................... 53 5.3.1. SUPAPolicyStructure Attributes ...................... 53
5.3.1.1. The Attribute "supaPolAdminStatus" ............. 53 5.3.1.1. The Attribute "supaPolAdminStatus" ............. 53
5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 53 5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 53
5.3.1.3. The Attribute "supaPolDeployStatus" ............ 54 5.3.1.3. The Attribute "supaPolDeployStatus" ............ 54
5.3.1.4. The Attribute "supaPolExecStatus" .............. 54 5.3.1.4. The Attribute "supaPolExecStatus" .............. 54
skipping to change at page 4, line 40 skipping to change at page 4, line 40
5.4.2. SUPAPolicyComponentStructure Relationships .......... 59 5.4.2. SUPAPolicyComponentStructure Relationships .......... 59
5.5. The Abstract Class "SUPAPolicyClause" .................... 59 5.5. The Abstract Class "SUPAPolicyClause" .................... 59
5.5.1. SUPAPolicyClause Attributes ......................... 60 5.5.1. SUPAPolicyClause Attributes ......................... 60
5.5.1.1. The Attribute "supaPolClauseExecStatus" ........ 60 5.5.1.1. The Attribute "supaPolClauseExecStatus" ........ 60
5.5.2. SUPAPolicyClause Relationships ...................... 61 5.5.2. SUPAPolicyClause Relationships ...................... 61
5.6. The Concrete Class "SUPAEncodedClause" ................... 61 5.6. The Concrete Class "SUPAEncodedClause" ................... 61
5.6.1. SUPAEncodedClause Attributes ........................ 61 5.6.1. SUPAEncodedClause Attributes ........................ 61
5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 61 5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 61
5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 61 5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 61
5.6.1.3. The Attribute "supaEncodedClauseResponse" ...... 62 5.6.1.3. The Attribute "supaEncodedClauseResponse" ...... 62
5.6.1.4. The Attribute "supaEncodedClauseLang[0..n]" .... 62
5.6.1.5. The Attribute "supaEncodedClauseResponse" ...... 62
5.6.2. SUPAEncodedClause Relationships ..................... 62 5.6.2. SUPAEncodedClause Relationships ..................... 62
5.7. The Abstract Class "SUPAPolicyComponentDecorator" ........ 62 5.7. The Abstract Class "SUPAPolicyComponentDecorator" ........ 62
5.7.1. The Decorator Pattern ............................... 63 5.7.1. The Decorator Pattern ............................... 63
5.7.2. SUPAPolicyComponentDecorator Attributes ............. 64 5.7.2. SUPAPolicyComponentDecorator Attributes ............. 64
5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 64 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 65
5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 64 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 65
5.7.3. SUPAPolicyComponentDecorator Relationships .......... 65 5.7.3. SUPAPolicyComponentDecorator Relationships .......... 65
5.7.3.1. The Aggregation 5.7.3.1. The Aggregation
"SUPAHasDecoratedPolicyComponent" .............. 65 "SUPAHasDecoratedPolicyComponent" .............. 66
5.7.3.2. The Association Class 5.7.3.2. The Association Class
"SUPAHasDecoratedPolicyComponentDetail" ........ 65 "SUPAHasDecoratedPolicyComponentDetail" ........ 66
5.7.3.2.1. The Attribute 5.7.3.2.1. The Attribute
"supaDecoratedConstraintEncoding" ......... 65 "supaDecoratedConstraintEncoding" ......... 66
5.7.3.2.2. The Attribute 5.7.3.2.2. The Attribute
"supaDecoratedConstraint[0..n]" ........... 66 "supaDecoratedConstraint[0..n]" ........... 67
5.7.4. Illustration of Constraints in the Decorator Pattern 66
Table of Contents (continued) Table of Contents (continued)
5.8. The Abstract Class "SUPAPolicyTerm" ...................... 67 5.7.4. Illustration of Constraints in the Decorator Pattern 67
5.8.1. SUPAPolicyTerm Attributes ........................... 68 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 68
5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 68 5.8.1. SUPAPolicyTerm Attributes ........................... 69
5.8.2. SUPAPolicyTerm Relationships ........................ 68 5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 69
5.9. The Concrete Class "SUPAPolicyVariable" .................. 68 5.8.2. SUPAPolicyTerm Relationships ........................ 69
5.9.1. Problems with the RFC3460 Version of PolicyVariable . 69 5.9. The Concrete Class "SUPAPolicyVariable" .................. 69
5.9.2. SUPAPolicyVariable Attributes ....................... 69 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 70
5.9.2.1. The Attribute "supaPolVarName" ................. 69 5.9.2. SUPAPolicyVariable Attributes ....................... 70
5.9.3. SUPAPolicyVariable Relationships .................... 69 5.9.2.1. The Attribute "supaPolVarName" ................. 70
5.10. The Concrete Class "SUPAPolicyOperator" ................. 69 5.9.3. SUPAPolicyVariable Relationships .................... 70
5.10.1. Problems with the RFC3460 Version .................. 70 5.10. The Concrete Class "SUPAPolicyOperator" ................. 70
5.10.2. SUPAPolicyOperator Attributes ...................... 70 5.10.1. Problems with the RFC3460 Version .................. 71
5.10.2.1. The Attribute "supaPolOpType" ................. 70 5.10.2. SUPAPolicyOperator Attributes ...................... 71
5.10.3. SUPAPolicyOperator Relationships ................... 70 5.10.2.1. The Attribute "supaPolOpType" ................. 71
5.11. The Concrete Class "SUPAPolicyValue" .................... 71 5.10.3. SUPAPolicyOperator Relationships ................... 71
5.11.1. Problems with the RFC3460 Version of PolicyValue ... 71 5.11. The Concrete Class "SUPAPolicyValue" .................... 72
5.11.2. SUPAPolicyValue Attributes ......................... 71 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 72
5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 71 5.11.2. SUPAPolicyValue Attributes ......................... 72
5.11.2.2. The Attribute "supaPolValEncoding" ............ 72 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 72
5.11.3. SUPAPolicyValue Relationships ...................... 72 5.11.2.2. The Attribute "supaPolValEncoding" ............ 73
5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 72 5.11.3. SUPAPolicyValue Relationships ...................... 73
5.12.1. SUPAGenericDecoratedComponent Attributes ........... 73 5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 73
5.12.1.1. The Attribute 5.12.1. SUPAGenericDecoratedComponent Attributes ........... 74
"supaVendorDecoratedCompContent[0..n]" ......... 73 5.12.1.1. The Attribute
5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 73 "supaVendorDecoratedCompContent[0..n]" ........ 74
5.12.2. SUPAGenericDecoratedComponent Relationships ........ 73 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 74
5.13. The Concrete Class "SUPAPolicyCollection" ............... 74 5.12.2. SUPAGenericDecoratedComponent Relationships ........ 74
5.13.1. Motivation ......................................... 74 5.13. The Concrete Class "SUPAPolicyCollection" ............... 75
5.13.2. Solution ........................................... 74 5.13.1. Motivation ......................................... 75
5.13.3. SUPAPolicyCollection Attributes .................... 75 5.13.2. Solution ........................................... 75
5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 75 5.13.3. SUPAPolicyCollection Attributes .................... 76
5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 75 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 76
5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 75 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 76
5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 75 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 76
5.13.3.5. The Attribute "supaPolCollectionType" ......... 76 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 76
5.13.4. SUPAPolicyCollection Relationships ................. 77 5.13.3.5. The Attribute "supaPolCollectionType" ......... 77
5.14. The Concrete Class "SUPAPolicySource" ..................... 77 5.13.4. SUPAPolicyCollection Relationships ................. 78
5.14.1. SUPAPolicySource Attributes ........................ 77 5.14. The Concrete Class "SUPAPolicySource" .................... 78
5.14.2. SUPAPolicySource Relationships ..................... 77 5.14.1. SUPAPolicySource Attributes ........................ 78
5.15. The Concrete Class "SUPAPolicyTarget" ................... 77 5.14.2. SUPAPolicySource Relationships ..................... 78
5.15.1. SUPAPolicyTarget Attributes ........................ 78 5.15. The Concrete Class "SUPAPolicyTarget" ................... 78
5.15.2. SUPAPolicyTarget Relationships ..................... 78 5.15.1. SUPAPolicyTarget Attributes ........................ 79
5.15.2. SUPAPolicyTarget Relationships ..................... 79
Table of Contents (continued) Table of Contents (continued)
5.16. The Abstract Class "SUPAPolicyMetadata" ................. 78 5.16. The Abstract Class "SUPAPolicyMetadata" ................. 79
5.16.1. SUPAPolicyMetadata Attributes ...................... 79 5.16.1. SUPAPolicyMetadata Attributes ...................... 80
5.16.1.1. The Attribute "supaPolMetadataDescription" .... 79 5.16.1.1. The Attribute "supaPolMetadataDescription" .... 80
5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 79 5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 80
5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 79 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 80
5.16.1.4. The Attribute "supaPolMetadataName" ........... 80 5.16.1.4. The Attribute "supaPolMetadataName" ........... 81
5.16.2. SUPAPolicyMetadata Relationships ................... 80 5.16.2. SUPAPolicyMetadata Relationships ................... 81
5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 80 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 81
5.16.2.2. The Abstract Class 5.16.2.2. The Association Class
"SUPAHasPolicyMetadataDetail" ................. 80 "SUPAHasPolicyMetadataDetail" ................. 81
5.16.2.2.1. The Attribute 5.16.2.2.1. The Attribute
"supaPolMetadataIsApplicable" ............ 80 "supaPolMetadataIsApplicable" ............ 81
5.16.2.2.2. The Attribute 5.16.2.2.2. The Attribute
"supaPolMetadataConstraintEncoding" ...... 81 "supaPolMetadataConstraintEncoding" ...... 82
5.16.2.2.3. The Attribute 5.16.2.2.3. The Attribute
"supaPolMetadataConstraint[0..n]" ........ 81 "supaPolMetadataConstraint[0..n]" ........ 82
5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 81 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 82
5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 82 5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 83
5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 82 5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" ...... 83
5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 82 5.17.1.2. The Attribute "supaPolMDValidPeriodStart" .... 83
5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 82 5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 83
5.18.1.1. The Attribute "supaPolMDValidPeriodEnd" ....... 82 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 83
5.18.1.2. The Attribute "supaPolMDValidPeriodStart" ..... 82 5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 83
5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 82 5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 83
5.18.2.1. The Aggregation "HasSUPAMetadataDecorator" .... 83 5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" .... 84
5.18.2.2. The Association Class 5.18.2.2. The Association Class
"HasSUPAMetadataDecoratorDetail" .............. 83 "SUPAHasMetadataDecoratorDetail" .............. 84
5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 83 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 84
5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 84 5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 85
5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 84 5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 85
5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 84 5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 85
5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 85 5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 86
5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 85 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 86
5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 85 5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 86
5.20.1.1. The Attribute "supaVersionMajor" .............. 85 5.20.1.1. The Attribute "supaVersionMajor" .............. 87
5.20.1.2. The Attribute "supaVersionMinor" .............. 86 5.20.1.2. The Attribute "supaVersionMinor" .............. 88
5.20.1.3. The Attribute "supaVersionRelType" ............ 86 5.20.1.3. The Attribute "supaVersionPatch" .............. 88
5.20.1.4. The Attribute "supaVersionTypeNum" ............ 86 5.20.1.4. The Attribute "supaVersionPreRelease" ......... 88
6. SUPA ECAPolicyRule Information Model .......................... 87 5.20.1.5. The Attribute "supaVersionBuildMetadata" ...... 89
6.1. Overview ................................................. 87 6. SUPA ECAPolicyRule Information Model .......................... 89
6.2. Constructing a SUPAECAPolicyRule ......................... 88 6.1. Overview ................................................. 89
6.3. Working With SUPAECAPolicyRules .......................... 89 6.2. Constructing a SUPAECAPolicyRule ......................... 91
6.4. The Abstract Class "SUPAECAPolicyRule" ................... 91 6.3. Working With SUPAECAPolicyRules .......................... 92
6.4.1. SUPAECAPolicyRule Attributes ........................ 92 6.4. The Abstract Class "SUPAECAPolicyRule" ................... 93
6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 93 6.4.1. SUPAECAPolicyRule Attributes ........................ 95
6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ........ 93 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 95
6.4.2. SUPAECAPolicyRule Relationships ..................... 93 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" ............. 93 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 96
6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 93 6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 96
6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 93 6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 96
6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 94 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 96
6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 94 6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 96
6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 94 6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 97
6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 95 6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 97
6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 95 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 98
6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 95 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 98
6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 95 6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 98
6.7. The Abstract Class "SUPABooleanClause" ................... 96 6.7. The Abstract Class "SUPABooleanClause" ................... 98
6.7.1. SUPABooleanClause Attributes ........................ 96 6.7.1. SUPABooleanClause Attributes ........................ 99
6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 97 6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 99
6.7.2. SUPABooleanClause Relationships ..................... 97 6.7.2. SUPABooleanClause Relationships ..................... 99
6.8. The Concrete Class "SUPABooleanClauseAtomic" ............. 97 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............ 100
6.8.1. SUPABooleanClauseAtomic Attributes .................. 97 6.8.1. SUPABooleanClauseAtomic Attributes ................. 100
6.8.2. SUPABooleanClauseAtomic Relationships ............... 97 6.8.2. SUPABooleanClauseAtomic Relationships .............. 100
6.9. The Concrete Class "SUPABooleanClauseComposite" .......... 97 6.9. The Concrete Class "SUPABooleanClauseComposite" ......... 100
6.9.1. SUPABooleanClauseComposite Attributes ................ 98 6.9.1. SUPABooleanClauseComposite Attributes .............. 100
6.9.1.1. The Attribute "supaBoolClauseBindValue" ........ 98 6.9.1.1. The Attribute "supaBoolClauseBindValue" ....... 101
6.9.1.2. The Attribute "supaBoolClauseIsCNF" ............ 98 6.9.1.2. The Attribute "supaBoolClauseIsCNF" ........... 101
6.9.2. SUPABooleanClauseComposite Relationships ............ 98 6.9.2. SUPABooleanClauseComposite Relationships ........... 101
6.9.2.1. The Aggregation "SUPAHasBooleanClause" ......... 98 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ........ 101
6.9.3. The Concrete Class "SUPAHasBooleanClauseDetail" ..... 99 6.9.3. The Association Class "SUPAHasBooleanClauseDetail" . 101
6.9.3.1. SUPAHasBooleanClauseDetail Attributes .......... 99 6.9.3.1. SUPAHasBooleanClauseDetail Attributes ......... 101
6.10. The Abstract Class "SUPAECAComponent" ................... 99 6.10. The Abstract Class "SUPAECAComponent" .................. 102
6.10.1. SUPAECAComponent Attributes ........................ 99 6.10.1. SUPAECAComponent Attributes ....................... 102
6.10.1.1. The Attribute supaECACompIsTerm .............. 100 6.10.1.1. The Attribute supaECACompIsTerm .............. 102
6.10.2. SUPAECAComponent Relationships .................... 100 6.10.2. SUPAECAComponent Relationships .................... 102
6.11. The Concrete Class "SUPAPolicyEvent" ................... 100 6.11. The Concrete Class "SUPAPolicyEvent" ................... 103
6.11.1. SUPAPolicyEvent Attributes ........................ 100 6.11.1. SUPAPolicyEvent Attributes ........................ 103
6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 100 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 103
6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 100 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 103
6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 101 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 103
6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 101 6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 103
6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 101 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 104
6.11.2. SUPAPolicyEvent Relationships ..................... 101 6.11.2. SUPAPolicyEvent Relationships ..................... 104
6.12. The Concrete Class "SUPAPolicyCondition" ............... 102 6.12. The Concrete Class "SUPAPolicyCondition" ............... 104
6.12.1. SUPAPolicyCondition Attributes .................... 102 6.12.1. SUPAPolicyCondition Attributes .................... 105
6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 102 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 105
6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 102 6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 105
6.12.2. SUPAPolicyEvent Relationships ..................... 102 6.12.2. SUPAPolicyEvent Relationships ..................... 105
6.13. The Concrete Class "SUPAPolicyAction" .................. 103 6.13. The Concrete Class "SUPAPolicyAction" .................. 106
6.13.1. SUPAPolicyAction Attributes ....................... 103 6.13.1. SUPAPolicyAction Attributes ....................... 106
6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 103 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 106
6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 104 6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 107
6.13.2. SUPAPolicyAction Relationships .................... 104 6.13.2. SUPAPolicyAction Relationships .................... 107
7. Examples ...................................................... 104 7. Examples ..................................................... 107
8. Security Considerations ...................................... 104 8. Security Considerations ..................................... 107
9. IANA Considerations ........................................... 105 9. IANA Considerations .......................................... 107
10. Contributors ................................................ 105 10. Contributors ................................................ 108
11. Acknowledgments ............................................. 105 11. Acknowledgments ............................................. 108
12. References .................................................. 105 12. References .................................................. 108
12.1. Normative References .................................... 105 12.1. Normative References ................................... 108
12.2. Informative References ................................. 105 12.2. Informative References ................................ 108
Authors' Addresses ............................................... 107 Authors' Addresses ............................................... 109
Appendix A. Brief Analyses of Previous Policy Work .............. 107 Appendix A. Brief Analyses of Previous Policy Work .............. 110
Appendix B. Mathematical Logic Terminology and Symbology ........ 114 1. Overview
Appendix C. SUPA Logic Statement Information Model .............. 114
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
their usage. The definition of common policy concepts also their usage. The definition of common policy concepts also
skipping to change at page 9, line 29 skipping to change at page 9, line 29
model that will be generated. model that will be generated.
This version of the information model focuses on defining one This version of the information model focuses on defining one
type of policy rule: the event-condition-action (ECA) policy rule. type of policy rule: the event-condition-action (ECA) policy rule.
Accordingly, this document defines two sets of model elements: Accordingly, this document defines two sets of model elements:
1. A framework for defining the concept of policy, 1. A framework for defining the concept of policy,
independent of how policy is represented or used; this is independent of how policy is represented or used; this is
called the SUPA Generic Policy Information Model (GPIM) called the SUPA Generic Policy Information Model (GPIM)
2. A framework for defining a policy model that uses the 2. A framework for defining a policy model that uses the
event-condition-action paradigm; this is called the SUPA event-condition-action (ECA) paradigm; this is called the
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 Appendices describe how the structure of the GPIM defines a
set of generic concepts that enables other types of policies, such set of generic concepts that enables other types of policies, such
as declarative (or "intent-based") policies, to be added later. as declarative (or "intent-based") policies, to be added later.
1.1. Introduction 1.1. Introduction
Simplified Use of Policy Abstractions (SUPA) defines an interface Simplified Use of Policy Abstractions (SUPA) defines a technology-
to a network management function that takes high-level, possibly independent neutral information model for creating high-level,
network-wide policies as input and creates element configuration possibly network-wide policies as input and producing element
snippets as output. SUPA addresses the needs of operators and configurations (either whole or snippets) as output. SUPA addresses
application developers to represent multiple types of policy the needs of operators, end-users, and application developers to
rules, which vary in the level of abstraction, to suit the needs represent multiple types of ECA policy rules, such as for traffic
of different actors [1], [10]. selection and configuration or security. These ECA policy rules may
vary in the level of abstraction to suit the needs of different
Different constituencies of users would like to use languages that actors (e.g., end-users vs. administrators) [1], [10].
use terminology and concepts that are familiar to each constituency.
Rather than require multiple software systems to be used for each
language, a common information model enables these different
languages to be mapped to terms in the information model. This
facilitiates the use of a single software system to generate data
models for each language. In the example shown in Figure 1 (which
is a simplified policy continuum [10]), each constituency needs
different grammars using different concepts and terminologies to
match their skill set. This is shown in Figure 1. A unified
information model is one way to build a consensual lexicon that
enables terms from one language to be mapped to terms of another
language.
+---------------------+
+---------------+ \| High-level Policies | \+-------------+
| Business User |----| Without Technical |----| Language #1 |
+---------------+ /| Terminology | /+-------------+
+---------------------+
+---------------------+
+---------------+ \| Policies That Use | \+-------------+
| Developer |----| Classes, Attributes,|----| Language #2 |
+---------------+ /| Relationships, ... | /+-------------+
+---------------------+
... ... ... Different constituencies of users would like to use terminology and
concepts that are familiar to each constituency. Rather than require
multiple software systems to be used for each constituency, a common
information model enables these different concepts and terms to be
mapped to elements in the information model. This facilitiates the
use of a single software system to generate data models for each
language. In the example shown in Figure 1 (which is a simplified
Policy Continuum [10]), each constituency uses different concepts
and terms (according to their skill sets and roles) to formulate
(ECA) policy rules that are useful for their job functions. A
unified information model is one way to build a consensual lexicon
that enables terms from one language to be mapped to terms of
another language. This approach enables the syntax of each language
to be modified appropriate to its user while keeping a common set
of semantics for all languages. This is shown in Figure 1.
+---------------------+ +-------------------+
+---------------+ \| Low-level Policies | \+-------------+ | Information Model |
| Admin |----| with Technology- |----| Language #n | | and one or more +<------------------------+
+---------------+ /| Specific Terms in a | /+-------------+ | Data Models | |
| Specific Language | +-------------------+ |
+---------------------+ |
+---------------------+ |
+---------------+ \| High-level Policies | \+-------------+ |
| Business User |----| Without Technical |----| Language #1 +<----+
+---------------+ /| Terminology | /+-------------+ |
+---------------------+ |
|
+---------------------+ |
+---------------+ \| Policies That Use | \+-------------+ |
| Developer |----| Classes, Attributes,|----| Language #2 +<----+
+---------------+ /| Relationships, ... | /+-------------+ |
+---------------------+ |
|
... ... ... |
|
+---------------------+ |
+---------------+ \| Low-level Policies | \+-------------+ |
| Admin |----| with Technology- |----| Language #n +<----+
+---------------+ /| Specific Terms in a | /+-------------+
| Specific Language |
+---------------------+
Figure 1. Different Constituencies Need Different Policies Figure 1. Different Constituencies Need Different Policies
More importantly, an information model defines concepts in a More importantly, an information model defines concepts in a
uniform way, enabling formal mapping processes to be developed to uniform way, enabling formal mapping processes to be developed to
translate the information model to a set of data models. This translate the information model to a set of data models. This
simplifies the process of constructing software to automate the simplifies the process of constructing software to automate the
policy management process. It also simplifies the language policy management process. It also simplifies the language
generation process, though that is beyond the scope of this generation process, though that is beyond the scope of this
document. document.
This common framework takes the form of an information model that This common framework takes the form of an information model that
is divided into one high-level module and any number of lower- is divided into one high-level module and one or more number of
level modules, where each lower-level module extends the concepts lower-level modules. A lower-level module extends the higher-level
of the single high-level module. Conceptually, a set of model module into a new domain; each lower-level domain module can itself
elements (e.g., classes, attributes, and relationships) are used be extended to model more granular domain-specific (but still
to define the Generic Policy Information Model (GPIM); this module technology- and vendor-independent) concepts as necessary.
defines a common set of policy management concepts that are
independent of the type of policy (e.g., imperative, procedural,
declarative, or otherwise). Then, any number of additional modules
are derived from the GPIM; each additional module MUST extend the
GPIM to define a new type of policy rule by adding to the GPIM.
(Note: using extensions preserves the core interoperability, as
compared with modification of the base GPIM, which would adversely
compromise interoperability.
The SUPA Eca Policy Rule Information Model (EPRIM) extends the Conceptually, a set of model elements (e.g., classes, attributes,
constraints, and relationships) are used to define the Generic
Policy Information Model (GPIM); this module defines a common set of
policy concepts that are independent of the type of policy (e.g.,
imperative, procedural, declarative, or otherwise). Then, any number
of additional modules can be derived from the GPIM; each additional
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
the model elements of the GPIM. The use of extensions preserves the
interoperability of this approach; if the base GPIM was modified,
then this would adversely compromise interoperability.
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. (The Appendices describe the SUPA Logic Statement (ECA) paradigm.
Information Model (LSIM), which shows how to extend the GPIM to
represent a collection of statements that are either Propositional
Logic (PL) or First-Order Logic (FOL), respectively. Both of these
logics are types of declarative logic. Note that the LSIM is
currently out of scope. However, it is outlined as a set of
Appendices in this document to get feedback on its utility.
1.2. Changes Since Version -04 1.2. Changes Since Version -00
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) The SUPAVendorDecoratedComponent class has been renamed to 1) Rewrote parts of the Introduction.
SUPAGenericDecoratedComponent, and its function has been 2) Clarified how to extend the GPIM and EPRIM
made more generic. 3) Redesigned the SUPAPolicyVersionMetadataDef class
2) A number of clarifications have been made in response to 4) Added Fully Qualified Path Names where applicable
questions from the SUPA mailing list. 5) Removed Appendices B and C (declarative policies)
3) The multiplicity of all relationships have been fine-tuned 6) Fixed typos
4) A **preliminary** YANG model [RFC6020] [RFC6991] has been
built from the GPIM; see [15].
5) Various additional typos have been fixed.
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.
3. Terminology 3. Terminology
This section defines acronyms, terms, and symbology used in the This section defines acronyms, terms, and symbology used in the
rest of this document. rest of this document.
3.1. Acronyms 3.1. Acronyms
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
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
This section defines the terminology that is used in this document. This section defines the terminology that is used in this document.
3.2.1. Core Terminology 3.2.1. Core Terminology
The following subsections define the terms "information model" and The following subsections define the terms "information model" and
"data model", as well as "container" and "policy container". "data model", as well as "container" and "policy container".
3.2.1.1. Information Model 3.2.1.1. Information Model
An information model is a representation of concepts of interest An information model is a representation of concepts of interest
to an environment in a form that is independent of data repository, to an environment in a form that is independent of data repository,
data definition language, query language, implementation language, data definition language, query language, implementation language,
and protocol. and protocol.
Note: this definition is more specific than that of [RFC3198], so Note: this definition is more specific than that of [RFC3198], so
as to focus on the properties of information models. That definition as to focus on the properties of information models. That definition
was: "An abstraction and representation of the entities in a managed was: "An abstraction and representation of the entities in a managed
environmentl, their properties, attributes and operations, and the environment, their properties, attributes and operations, and the
way that they relate to each other. It is independent of any way that they relate to each other. It is independent of any
specific repository, software usage, protocol, or platform." specific repository, software usage, protocol, or platform."
3.2.1.2. Data Model 3.2.1.2. Data Model
A data model is a representation of concepts of interest to an A data model is a representation of concepts of interest to an
environment in a form that is dependent on data repository, data environment in a form that is dependent on data repository, data
definition language, query language, implementation language, and definition language, query language, implementation language, and/or
protocol (typically, but not necessarily, all three). protocol (typically, but not necessarily, all five).
Note: this definition is more specific than that of [RFC3198], so Note: this definition is more specific than that of [RFC3198], so
as to focus on the properties of data models that are generated as to focus on the properties of data models that are generated
from information models. That definition was: "A mapping of the from information models. That definition was: "A mapping of the
contents of an information model into a form that is specific to a contents of an information model into a form that is specific to a
particular type of data store or repository." particular type of data store or repository."
3.2.1.3. Abstract Class 3.2.1.3. Class
A class is a set of objects that exhibit a common set of
characteristics and behavior.
3.2.1.3.1. Abstract Class
An abstract class is a class that cannot be directly instantiated. An abstract class is a class that cannot be directly instantiated.
It MAY have abstract or concrete subclasses. It is denoted with a It MAY have abstract or concrete subclasses. It is denoted with a
capital A near the top-left side of the class. capital A (for abstract) near the top-left side of the class.
3.2.1.4. Concrete Class 3.2.1.3.2. Concrete Class
A concrete class is a class that can be directly instantiated. Note A concrete class is a class that can be directly instantiated. Note
that classes are either abstract or concrete. In addition, once a that classes are either abstract or concrete. In addition, once a
class has been defined as concrete in the hierarchy, all of its class has been defined as concrete in the hierarchy, all of its
subclasses MUST also be concrete. It is denoted with a capital C subclasses MUST also be concrete. It is denoted with a capital C
near the top-left side of the class. (for concrete) near the top-left side of the class.
3.2.1.5. Container 3.2.1.4. Container
A container is an object whose instances may contain zero or more A container is an object whose instances may contain zero or more
additional objects, including container objects. A container additional objects, including container objects. A container
provides storage, query, and retrieval of its contained objects provides storage, query, and retrieval of its contained objects
in a well-known, organized way. in a well-known, organized way.
3.2.1.6. PolicyContainer 3.2.1.5. PolicyContainer
In this document, a PolicyContainer is a special type of container In this document, a PolicyContainer is a special type of container
that provides at least the following three functions: that provides at least the following three functions:
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 OAMP 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 implementation
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
prefix "SUPA" is used for all classes and relationships defined prefix "SUPA" is used for all classes and relationships defined
in this model to ensure name uniqueness. Similarly, the prefix in this model to ensure name uniqueness. Similarly, the prefix
"supa" is defined for all SUPA class attributes. "supa" is defined for all SUPA class attributes.
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. 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 an ECA policy rule, 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 at least create, read, query (a this context, "manage" means that one or more of the following six
more complex operation than read that may involve pre- and/or post- fundamental operations are supported: create, read, write, delete,
processing of the results of the operation), update, and delete start, and stop) [16].
functions are supported.
3.2.2.3. SUPAPolicyClause 3.2.2.3. SUPAPolicyClause
A SUPAPolicyClause is an abstract class. Its subclasses define A SUPAPolicyClause is an abstract class. Its subclasses define
different types of clauses that are used to create the content different types of clauses that are used to create the content
for different types of SUPAPolicies. for different types of SUPAPolicies.
For example, the SUPABooleanClause subclass models the content For example, the SUPABooleanClause subclass models the content
of a SUPAPolicy as a Boolean clause, where each Boolean clause of a SUPAPolicy as a Boolean clause, where each Boolean clause
is made up of a set of reusable objects. In contrast, a is made up of a set of reusable objects. In contrast, a
SUPAEncodedClause encodes the entire clause as a set of SUPAEncodedClause encodes the entire clause as a set of
attributes. All types of SUPAPolicies MUST use one or more attributes. All types of SUPAPolicies MUST use one or more
SUPAPolicyClauses to construct a SUPAPolicy. SUPAPolicyClauses to construct a SUPAPolicy.
3.2.2.4. SUPAECAPolicyRule 3.2.2.4. SUPAECAPolicyRule
An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an
abstract class that is a type of PolicyContainer. It represents abstract class that is a type of PolicyContainer. It represents
a policy rule as a three-tuple, consisting of an event, a a policy rule as a three-tuple, consisting of an event, a
condition, and an action clause. In an information model, this condition, and an action clause. In an information model, this
takes the form of three different aggregations, one for each takes the form of three different aggregations, one for each
clause. Each clause MUST be represented by at least one clause. Each clause MUST be represented by at least one
SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain
zero or more SUPAPolicySources, zero or more SUPAPolicyTargets, zero or more SUPAPolicySources, zero or more SUPAPolicyTargets,
and zero or more SUPAPolicyMetadata objects. and zero or more SUPAPolicyMetadata objects. Note that for this
version of this document, ECA Policy Rules are the **only**
types of Policies that are defined.
3.2.2.5. SUPAMetadata 3.2.2.5. SUPAMetadata
Metadata is, literally, data about data. SUPAMetadata is an Metadata is, literally, data about data. SUPAMetadata is an
abstract class that contains prescriptive and/or descriptive abstract class that contains prescriptive and/or descriptive
information about the object(s) to which it is attached. While information about the object(s) to which it is attached. While
metadata can be attached to any information model element, this metadata can be attached to any information model element, this
document only considers metadata attached to classes and document only considers metadata attached to classes and
relationships. relationships.
When defined in an information model, each instance of the When defined in an information model, each instance of the
SUPAMetadata class MUST have its own aggregation relationship SUPAMetadata class MUST have its own aggregation relationship
with the set of objects that it applies to. However, a data model with the set of objects that it applies to. However, a data model
MAY map these definitions to a more efficient form (e.g., MAY map these definitions to a more efficient form (e.g.,
flattening the object instances into a single object instance). flattening the object instances into a single object instance).
3.2.2.6. SUPAPolicyTarget 3.2.2.6. SUPAPolicyTarget
SUPAPolicyTarget is an abstract class that defines a set of SUPAPolicyTarget is an abstract class that defines a set of
managed objects that may be affected by the actions of a managed objects that may be affected by the actions of a
SUPAPolicyClause. A SUPAPolicyTarget may use one or more SUPAPolicyClause. A SUPAPolicyTarget may use one or more
mechanisms to identify the set of managed objects that it mechanisms to identify the set of managed objects that it
affects; examples include OIDs and URIs. affects; examples include OIDs and URIs.
When defined in an information model, each instance of the When defined in an information model, each instance of the
SUPAPolicyTarget class MUST have its own aggregation SUPAPolicyTarget class MUST have its own aggregation
relationship with each SUPAPolicy that uses it. However, a relationship with each SUPAPolicy that uses it. However, a
data model MAY map these definitions to a more efficient form data model MAY map these definitions to a more efficient form
(e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and
SUPAPolicy object instances into a single object instance). SUPAPolicy object instances into a single object instance).
3.2.2.7. SUPAPolicySource 3.2.2.7. SUPAPolicySource
SUPAPolicySource is an abstract class that defines a set of SUPAPolicySource is an abstract class that defines a set of
managed objects that authored this SUPAPolicyClause. This is managed objects that authored this SUPAPolicyClause. This is
required for auditability. A SUPAPolicySource may use one or more required for auditability and authorization policies, as well
mechanisms to identify the set of managed objects that authored it; as some forms of deontic and alethic logic.
examples include OIDs and URIs. Specifically, policy CRUD MUST be
subject to authentication and authorization, and MUST be auditable. A SUPAPolicySource may use one or more mechanisms to identify the
Note that the mechanisms for doing these three operations are set of managed objects that authored it; examples include OIDs and
currently not included, and are for further discussion. URIs. Specifically, policy CRUD MUST be subject to authentication
and authorization, and MUST be auditable. Note that the mechanisms
for doing these three operations are currently not included, and
are for further discussion.
When defined in an information model, each instance of the When defined in an information model, each instance of the
SUPAPolicySource class MUST have its own aggregation relationship SUPAPolicySource class MUST have its own aggregation relationship
with each SUPAPolicy that uses it. However, a data model MAY map with each SUPAPolicy that uses it. However, a data model MAY map
these definitions to a more efficient form (e.g., flattening the these definitions to a more efficient form (e.g., flattening the
SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances
into a single object instance). into a single object instance).
3.2.3. Modeling Terminology 3.2.3. Modeling Terminology
The following terms define different types of relationships used The following terms define different types of relationships used
in the information models of the SUPA Generic Policy Information in the information models of the SUPA Generic Policy Information
Model (GPIM). Model (GPIM).
3.2.3.1. Inheritance 3.2.3.1. Inheritance
Inheritance makes an entity at a lower level of abstraction (e.g., Inheritance makes an entity at a lower level of abstraction (e.g.,
the subclass) a type of an entity at a higher level of abstraction the subclass) a type of an entity at a higher level of abstraction
(e.g., the superclass). Any attributes and relationships that are (e.g., the superclass). Any attributes and relationships that are
defined for the superclass are also defined for the subclass. defined for the superclass are also defined for the subclass.
However, a subclass does NOT change the characteristics or behavior However, a subclass does NOT change the characteristics or behavior
of the attributes or relationships of the superclass that it of the attributes or relationships of the superclass that it
inherits from. Formally, this is called the Liskov Substitution inherits from. Formally, this is called the Liskov Substitution
Principle [7]. This principle is one of the key characteristics Principle [7]. This principle is one of the key characteristics
that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. that is NOT followed in [4], [6], [RFC3060], and [RFC3460].
A subclass MAY add new attributes and relationships that refine A subclass MAY add new attributes and relationships that refine
the characteristics and/or behavior of it compared to its the characteristics and/or behavior of it compared to its
superclass. A subclass MUST NOT change inherited attributes or superclass. A subclass MUST NOT change inherited attributes or
relationships. relationships.
3.2.3.2. Relationship 3.2.3.2. Relationship
A relationship is a generic term that represents how a first set A relationship is a generic term that represents how a first set
of entities interact with a second set of entities. A recursive of entities interact with a second set of entities. A recursive
relationship sets the first and second entity to the same entity. relationship sets the first and second entity to the same entity.
There are three basic types of relationships, as defined in the There are three basic types of relationships, as defined in the
subsections below: associations, aggregations, and compositions. subsections below: associations, aggregations, and compositions.
A subclass MUST NOT change the multiplicity (see section 3.2.3.7) A subclass MUST NOT change the multiplicity (see section 3.2.3.7)
of a relationship that it inherits. A subclass MUST NOT change any of a relationship that it inherits. A subclass MUST NOT change any
attributes of a relation that it inherits that is realized using attributes of a relation that it inherits that is realized using
an association class (see section 3.2.3.6). an association class (see section 3.2.3.6).
3.2.3.3. Association 3.2.3.3. Association
An association represents a generic dependency between a first An association represents a generic dependency between a first
and a second set of entities. In an information model, an and a second set of entities. In an information model, an
association MAY be represented as a class. association MAY be represented as a class.
3.2.3.4. Aggregation 3.2.3.4. Aggregation
An aggregation is a stronger type (i.e., more restricted An aggregation is a stronger type (i.e., more restricted
semantically) of association, and represents a whole-part semantically) of association, and represents a whole-part
dependency between a first and a second set of entities. Three dependency between a first and a second set of entities. Three
objects are defined by an aggregation: the first entity, the objects are defined by an aggregation: the first entity, the
second entity, and a new third entity that represents the second entity, and a new third entity that represents the
combination of the first and second entities. combination of the first and second entities.
The entity owning the aggregation is referred to as the The entity owning the aggregation is referred to as the
"aggregate", and the entity that is aggregated is referred to as "aggregate", and the entity that is aggregated is referred to as
the "part". In an information model, an aggregation MAY be the "part". In an information model, an aggregation MAY be
represented as a class. represented as a class.
3.2.3.5. Composition 3.2.3.5. Composition
A composition is a stronger type (i.e., more restricted A composition is a stronger type (i.e., more restricted
semantically) of aggregation, and represents a whole-part semantically) of aggregation, and represents a whole-part
dependency with two important behaviors. First, an instance of the dependency with two important behaviors. First, an instance of the
part is included in at most one instance of the aggregate at a part is included in at most one instance of the aggregate at a
time. Second, any action performed on the composite entity (i.e., time. Second, any action performed on the composite entity (i.e.,
the aggregate) is propagated to its constituent part objects. the aggregate) is propagated to its constituent part objects.
For example, if the composite entity is deleted, then all of its For example, if the composite entity is deleted, then all of its
constituent part entities are also deleted. This is not true of constituent part entities are also deleted. This is not true of
aggregations or associations - in both, only the entity being aggregations or associations - in both, only the entity being
deleted is actually removed, and the other entities are unaffected. deleted is actually removed, and the other entities are unaffected.
In an information model, a composition MAY be represented as In an information model, a composition MAY be represented as
a class. a class.
3.2.3.6. Association Class 3.2.3.6. Association Class
A relationship may be implemented as an association class. This is A relationship may be implemented as an association class. This is
used to define the relationship as having its own set of features. used to define the relationship as having its own set of features.
(Note: in this document, all relationships are implemented as
association classes for consistency and to simplify implementation.)
More specifically, if the relationship is implemented as an More specifically, if the relationship is implemented as an
association class, then the attributes of the association class, as association class, then the attributes of the association class, as
well as other relationships that the association class participates well as other relationships that the association class participates
in, may be used to define the semantics of the relationship. If the in, may be used to define the semantics of the relationship. If the
relationship is not implemented as an association class, then no relationship is not implemented as an association class, then no
additional semantics (beyond those defined by the type of the additional semantics (beyond those defined by the type of the
relationship) are expressed by the relationship. relationship) are expressed by the relationship.
3.2.3.7. Multiplicity 3.2.3.7. Multiplicity
A specification of the range of allowable cardinalities that a set A specification of the range of allowable cardinalities that a set
of entities may assume. This is always a pair of ranges, such as of entities may assume. This is always a pair of ranges, such as
1 - 1 or 0..n - 2..5. 1 - 1 or 0..n - 2..5.
3.2.3.8. Navigability 3.2.3.8. Navigability
A relationship may have a restriction on the ability of an object A relationship may restrict one object from accessing the other
at one end of the relationship to access the object at the other object. This document defines two choices:
end of the relationship. This document defines two choices:
1. Each object is navigable by the other, which is indicated 1. Each object is navigable by the other, which is indicated
by NOT providing any additional symbology, or by NOT providing any additional symbology, or
2. An object A can navigate to object B, but object B cannot 2. An object A can navigate to object B, but object B cannot
navigate to object A. This is indicated by an open-headed navigate to object A. This is indicated by an open-headed
arrow pointing to the object that cannot navigate to the arrow pointing to the object that cannot navigate to the
other object. In this example, the arrow would be pointing other object. An example is shown below:
at object B.
Examples of navigability are:
+---------+ 3..4 +---------+ +---------+ 3..4 +---------+
| | 1..2 \| | | | 1..2 \| |
| Class A |--------------| Class B | | Class A |--------------| Class B |
| | /| | | | /| |
+---------+ +---------+ +---------+ +---------+
This is an association. Class A can navigate to Class B, but Class The above figure shows a navigability restriction. Class A can
B cannot navigate to Class A. This is a mandatory association, navigate to Class B, but Class B cannot navigate to Class A. This is
since none of the multiplicities contain a '0'. This association a mandatory association, since none of the multiplicities contain a
reads as follows: '0'. This association reads as follows:
Class A depends on 3 to 4 instances of Class B, and Class A depends on 3 to 4 instances of Class B, and
Class B depends on 1 to 2 instances of Class A. Class B depends on 1 to 2 instances of Class A.
3.3. Symbology 3.3. Symbology
The following symbology is used in this document: The following symbology is used in this document.
3.3.1. Inheritance 3.3.1. Inheritance
Inheritance: a subclass inherits the attributes and relationships Inheritance: a subclass inherits the attributes and relationships
of its superclass, as shown below: of its superclass, as shown below:
+------------+ +------------+
| Superclass | | Superclass |
+------+-----+ +------+-----+
/ \ / \
I I
I I
I I
+------+-----+ +------+-----+
| Subclass | | Subclass |
+------------+ +------------+
3.3.2. Association 3.3.2. Association
Association: Class B depends on Class A, as shown below: Association: Class B depends on Class A, as shown below:
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ | | \| | +---------+ +---------+ | | \| |
| Class A |------| Class B | | Class A |------| Class B | | Class A |------| Class B | | Class A |------| Class B |
+---------+ +---------+ | | /| | +---------+ +---------+ | | /| |
+---------+ +---------+ +---------+ +---------+
association with no association with association with no association with
navigability restrictions navigability restrictions navigability restrictions navigability restrictions
3.3.3. Aggregation 3.3.3. Aggregation
Aggregation: Class B is the part, Class A is the aggregate, Aggregation: Class B is the part, Class A is the aggregate,
as shown below: as shown below:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| |/ \ +---------+ | |/ \ \| | | |/ \ +---------+ | |/ \ \| |
| Class A | A ---| Class B | | Class A | A ------| Class B | | Class A | A ---| Class B | | Class A | A ------| Class B |
| |\ / +---------+ | |\ / /| | | |\ / +---------+ | |\ / /| |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
aggregation with no aggregation with aggregation with no aggregation with
navigability restrictions navigability restrictions navigability restrictions navigability restrictions
3.3.4. Composition 3.3.4. Composition
Composition: Class B is the part, Class A is the composite, Composition: Class B is the part, Class A is the composite,
as shown below: as shown below:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| |/ \ +---------+ | |/ \ \| | | |/ \ +---------+ | |/ \ \| |
| Class A | C ---| Class B | | Class A | C ------| Class B | | Class A | C ---| Class B | | Class A | C ------| Class B |
| |\ / +---------+ | |\ / /| | | |\ / +---------+ | |\ / /| |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
composition with no composition with composition with no composition with
navigability restrictions navigability restrictions navigability restrictions navigability restrictions
3.3.5. Association Class 3.3.5. Association Class
Association Class: Class C is the association class implementing Association Class: Class C is the association class implementing
the relationship D between classes A and B the relationship D between classes A and B
+---------+ +---------+ +---------+ +---------+
| Class A |----+-----| Class B | | Class A |----+-----| Class B |
+---------+ ^ +---------+ +---------+ ^ +---------+
| |
| |
+----------+----------+ +----------+----------+
| Association Class C | | Association Class C |
skipping to change at page 21, line 13 skipping to change at page 21, line 13
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 motivation for the policy abstractions
that are used in SUPA. The following abstractions are provided: that are used in 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 is a o Each clause is defined as a Boolean expression, and MAY
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 statmeents, 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, separates 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
skipping to change at page 21, line 54 skipping to change at page 22, line 5
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 SUPAECAPolicyRule
(see section 6.13). (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.
Please see the Appendices for experimental definitions of 4.1. Motivation
declarative policies. Note that they also are derived from the
GPIM, and extend (but do not change) the above abstractions.
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
network administrator may want to define a more concrete policy network administrator may want to define a more concrete policy
skipping to change at page 23, line 5 skipping to change at page 23, line 5
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.
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.
skipping to change at page 23, line 40 skipping to change at page 23, line 40
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 more formal form (e.g.,
Datalog (as in OpenStack Congress). It may also be necessary to Datalog (as in OpenStack Congress). It may also be necessary to
translate a Policy to a different level of abstraction. For 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.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 2 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
skipping to change at page 24, line 28 skipping to change at page 24, line 28
/ \ / \ / \ / \
| | | |
| | | |
+-----------+-----------+ +-----------+------------+ +-----------+-----------+ +-----------+------------+
| 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 2. Overview of SUPA Policy Rule Abstractions
This draft defines the GPIM and EPRIM. Note that there is only This draft defines the GPIM and EPRIM. This draft further assumes
ONE GPIM and ONE EPRIM. While both can be extended, it is that the SUPA Information Model is made up of either the GPIM or the
important to limit the number of information models to one, in combination of the GPIM and the EPRIM. Extensions to both the GPIM
order to avoid defining conflicting concepts at this high a and the EPRIM can be made as long as these extensions do not
level of abstraction. Similarly, if the GPIM and EPRIM are part conflict with the content and structure defined in the GPIM and
of another information model, then they should collectively EPRIM. If the GPIM and EPRIM are part of another information model,
still define a single information model. The GPIM defines the then they should collectively still define a single information
following concepts: model. The GPIM defines the following concepts:
o A class defining the top of the GPIM class hierarchy, called o A class defining the top of the GPIM class hierarchy, called
SUPAPolicyObject SUPAPolicyObject
o Four subclasses of SUPAPolicyObject, representing: o Four subclasses of SUPAPolicyObject, representing:
o the top of the PolicyRule hierarchy, called o the top of the Policy hierarchy, called
SUPAPolicyStructure SUPAPolicyStructure
o the top of the PolicyRule component hierarchy, called o the top of the Policy component hierarchy, called
SUPAPolicyComponentStructure SUPAPolicyComponentStructure
o PolicySource o PolicySource
o PolicyTarget o PolicyTarget
The SUPAPolicyStructure class is the superclass for all types of The SUPAPolicyStructure class is the superclass for all types of
Policies (e.g., imperative, declarative, and others). This Policies (e.g., imperative, declarative, and others). This
document is currently limited to imperative (e.g., ECA) policies. document is currently limited to imperative (e.g., ECA) policies.
However, care has been taken to ensure that the attributes and However, care has been taken to ensure that the attributes and
relationships of the SUPAPolicyStructure class are extensible, relationships of the SUPAPolicyStructure class are extensible,
and can be used for more types of policies than just ECA policies. and can be used for more types of policies than just ECA policies.
skipping to change at page 25, line 27 skipping to change at page 25, line 27
+----+----------------+ 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 +-------+----------+ I I I +-------+----------+ I I
I | SUPAPolicySource | I I I | SUPAPolicySource | I I
I +------------------+ I I I +------------------+ I I
I I I I I I
I +-------------+ I I +-------------+ I
I I I I I +-----+-------+
I C I +-----+-------+ I C I I I
I +-------+----------+ I I I +-------+----------+ A I I
I | SUPAPolicyTarget | A I I I | SUPAPolicyTarget | +--------+---------+ I
I +------------------+ +--------+---------+ I I +------------------+ | SUPAPolicyClause | I
A I | SUPAPolicyClause | I A I +------------------+ I
+-----+------------+ +------------------+ I +-----+------------+ I
| SUPAECAPolicyRule| I | SUPAECAPolicyRule| A I
+------------------+ A I +------------------+ +--------------------+---------+
+--------------------+---------+
| SUPAPolicyComponentDecorator | | SUPAPolicyComponentDecorator |
+------------------------------+ +------------------------------+
Figure 3. Functional View of the Top-Level GPIM Figure 3. 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 to 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
A SUPAPolicyObject serves as a single root of the SUPA system A SUPAPolicyObject serves as a single root of the SUPA system
(i.e., all other classes in the model are subclasses of the (i.e., all other classes in the model are subclasses of the
SUPAPolicyObject class). This simplifes code generation and SUPAPolicyObject class) except for the Metadata objects, which are
in a separate class hierarchy. This simplifies code generation and
reusability. It also enables SUPAPolicyMetadata objects to be reusability. It also enables SUPAPolicyMetadata objects to be
attached to any appropriate subclass of SUPAPolicyObject. attached to any appropriate subclass of SUPAPolicyObject.
4.3.2. SUPAPolicyStructure 4.3.2. SUPAPolicyStructure
SUPAPolicyStructure is an abstract superclass that is the base SUPAPolicyStructure is an abstract superclass that is the base
class for defining different types of policies (however, in this class for defining different types of policies (however, in this
version of this document, only ECA policy rules are modeled). It version of this document, only ECA policy rules are modeled). It
serves as a convenient aggregation point to define atomic (i.e., serves as a convenient aggregation point to define atomic (i.e.,
individual policies that can be used independently) and composite individual policies that can be used independently) and composite
skipping to change at page 28, line 45 skipping to change at page 28, line 45
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. 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:
1. It uses metadata to define how its content is described 1. It uses metadata to define how its content is described
and/or prescribed and/or prescribed
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 OAMP operations. 3. It provides a convenient control point for OAMP operations.
skipping to change at page 30, line 42 skipping to change at page 30, line 42
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 5. 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, made up of one or more event An ECA policy rule is a 3-tuple, which is made up of an event
clauses, one or more condition clauses, and one or more action clause, a condition clause, and an action clause. Each of these
clauses. Each clause may be viewed as a predicate, as it provides three types of clauses may in turn be made up of a Boolean
a TRUE or FALSE output. The canonical form of a clause is a combination of clauses of that type. Each clause may be viewed as
3-tuple of the form "variable operator value", and can be made a predicate, as it provides a TRUE or FALSE output. The canonical
into more complex Boolean expressions. For example, the form of a clause is a 3-tuple of the form "variable operator value",
SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two and can be made into more complex Boolean expressions. For example,
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 A A
+---------------------------+ +------------------+ +---------------------------+ +------------------+
| SUPAPolicyStructure | | SUPAPolicyClause | | SUPAPolicyStructure | | SUPAPolicyClause |
+---------+---------+-------+ +--------+----+----+ +---------+---------+-------+ +--------+----+----+
/ \ / \ 0..1 1..n / \ / \ / \ / \ 0..1 1..n / \ / \
I A | I I A | I
I \ / | I I \ / | I
I | | I I | | I
I | SUPAHasPolicyClause | I I | SUPAHasPolicyClause | I
I +------------------------+ I I +------------------------+ I
A I A I A I A I
+------+------------+ +----------+-------+ +------+------------+ +----------+-------+
| SUPAECAPolicyRule | | SUPAPolicyClause | | SUPAECAPolicyRule | | SUPAPolicyClause |
+-------------------+ +------------------+ +-------------------+ +------------------+
Figure 6. SUPAECAPolicyRule Aggregating SUPAPolicyClauses Figure 6. SUPAECAPolicyRule Aggregating SUPAPolicyClauses
Note that the aggregation SUPAHasPolicyClause in Figure 6 is 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.
skipping to change at page 35, line 52 skipping to change at page 35, line 51
| SUPAPolicyTerm | I | SUPAPolicyCollection | I | SUPAPolicyTerm | I | SUPAPolicyCollection | I
+----------------+ I +----------------------+ I +----------------+ I +----------------------+ I
(for defining I (for defining sets and/or I (for defining I (for defining sets and/or I
clauses in I groups of objects) I clauses in I groups of objects) I
canonical form) I I canonical form) I I
I I I I
C I A I C I A I
+----------------+--------------+ +---------+--------+ +----------------+--------------+ +---------+--------+
| SUPAGenericDecoratedComponent | | SUPAECAComponent | | SUPAGenericDecoratedComponent | | SUPAECAComponent |
+-------------------------------+ +------------------+ +-------------------------------+ +------------------+
(for decorating concrete (for defiing reusable (for decorating concrete (for defining reusable
subclasses of SUPAPolicyClause) event, condition, subclasses of SUPAPolicyClause) event, condition,
and action objects) and action objects)
Figure 10. Subclasses of SUPAPolicyComponentDecorator Figure 10. Subclasses of SUPAPolicyComponentDecorator
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 SUPAPolicyComponentDecorator subclasses, since
the SUPAEncodedClause already completely defines the content of the SUPAEncodedClause already completely defines the content of
the SUPAPolicyClause. the SUPAPolicyClause.
skipping to change at page 39, line 17 skipping to change at page 39, line 17
A SUPAPolicyTarget defines the set of managed entities that a A SUPAPolicyTarget defines the set of managed entities that a
SUPAPolicy is applied to. This is useful for debugging, as well as SUPAPolicy is applied to. This is useful for debugging, as well as
when the nature of the application requires the set of managed when the nature of the application requires the set of managed
entities affected by a Policy to be explicitly identified. This is entities affected by a Policy to be explicitly identified. This is
determined by two conditions: determined by two conditions:
1) The set of managed entities that are to be affected by the 1) The set of managed entities that are to be affected by the
SUPAPolicy must all agree to play the role of a SUPAPolicy must all agree to play the role of a
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 ability 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 12 showed how SUPAPolicyTargets are attached to
SUPAECAPolicyRules. SUPAECAPolicyRules.
skipping to change at page 40, line 21 skipping to change at page 40, line 21
Note that this also violates a number of well-known software Note that this also violates a number of well-known software
architecture principles, including: architecture principles, including:
o the Liskov Substitution Principle [13] o the Liskov Substitution Principle [13]
(if A is a subclass of B, then objects instantiated from (if A is a subclass of B, then objects instantiated from
class B may be replaced with objects instantiated from class B may be replaced with objects instantiated from
class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS) class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS)
o the Single Responsibility Principle [14] o the Single Responsibility Principle [14]
(every class should have responsibility over one, and only (every class should have responsibility over one, and only
one, part of the functionality provided by the program) one, part of the functionality provided by the program)
o the Open/Closed Principle (software should be open for
extension, but closed for modification) [17]
o the Interface-Segreation Principle (clients should not be
forced to depend on methods that they do not use) [14]
o the Dependency Inversion Principle (high-level modules should
not depend on low-level modules; both should depend on
abstractions) [14]
Most models use inheritance, not composition. The former is Most models use inheritance, not composition. The former is
simpler, but has some well-known problems. One is called "weak simpler, but has some well-known problems. One is called "weak
encapsulaton", meaning that a subclass can use attributes and encapsulaton", meaning that a subclass can use attributes and
methods of a superclass, but if the superclass changes, the methods of a superclass, but if the superclass changes, the
subclass may break. Another is that each time a new object is subclass may break. Another is that each time a new object is
required, a new subclass must be created. These problems are required, a new subclass must be created. These problems are
present in [RFC3460], [4], and [6]. present in [RFC3460], [4], and [6].
Composition is an alternative that provides code that is easier to Composition is an alternative that provides code that is easier to
skipping to change at page 42, line 42 skipping to change at page 42, line 42
programming, of software systems. In contrast to design, programming, of software systems. In contrast to design,
development emphasizes constructing software artifacts via coding development emphasizes constructing software artifacts via coding
and documentation. and documentation.
Deployment may be described as the process of releasing software. Deployment may be described as the process of releasing software.
It includes all of the operations required to assemble a completed It includes all of the operations required to assemble a completed
software product. It typically also includes the process of software product. It typically also includes the process of
preparing a software product for execution (e.g., assembling a set preparing a software product for execution (e.g., assembling a set
of software products into a larger product, determining if the of software products into a larger product, determining if the
consumer site has appropriate resources to install and execute the consumer site has appropriate resources to install and execute the
software product, and collecting information on the feasbility of software product, and collecting information on the feasibility of
using the software product). This contrasts with the execution using the software product). This contrasts with the execution
process, which is the set of processes that follow deployment. process, which is the set of processes that follow deployment.
In summary, exemplar states in the policy lifecycle process In summary, exemplar states in the policy lifecycle process
include: include:
o Design: determining how the policy-based management o Design: determining how the policy-based management
system will operate system will operate
o Development: documenting, programming, testing, and o Development: documenting, programming, testing, and
maintaining policies and policy components maintaining policies and policy components
skipping to change at page 45, line 18 skipping to change at page 45, line 18
+--------+---------+ +--------+---------+
/ \ 0..n / \ 0..n
A A
\ / \ /
| A | A
| 0..n +--------------------+ | 0..n +--------------------+
| SUPAHasPolicyMetadata \| | | SUPAHasPolicyMetadata \| |
+-------------+-----------------+ SUPAPolicyMetadata | +-------------+-----------------+ SUPAPolicyMetadata |
^ /| | ^ /| |
| +------+------+------+ | +------+------+------+
A | / \ | 1..n C | / \ | 1..n
+-------------+---------------+ I | +-------------+---------------+ I |
1..n | | I | 1..n | | I |
+----------+ SUPAHasPolicyMetadataDetail | I | +----------+ SUPAHasPolicyMetadataDetail | I |
| | | I | | | | I |
| +-----------------------------+ I | | +-----------------------------+ I |
| I | | I |
| (gets/sets values of attributes and/or I | | (gets/sets values of attributes and/or I |
| methods of the SUPAHasPolicyMetadataDetail I | | methods of the SUPAHasPolicyMetadataDetail I |
| class; this affects which SUPAPolicyMetadata I | | class; this affects which SUPAPolicyMetadata I |
| objects can be attached to which policies I | | objects can be attached to which policies I |
skipping to change at page 45, line 50 skipping to change at page 45, line 50
| | 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 PolicyObjectHasMetadata and policy components SUPAHasMetadataDecorator
Figure 14. SUPAPolicyMetadata Subclasses and Relationships Figure 14. SUPAPolicyMetadata Subclasses and Relationships
Since a class encapsulates attributes, methods, and behavior, Since a class encapsulates attributes, methods, and behavior,
defining the Identification Object in the above example as a type defining the Identification Object in the above example as a type
of SUPAPolicyMetadata object enables the decorator pattern to be of SUPAPolicyMetadata object enables the decorator pattern to be
used to attach all or part of that object to other objects that used to attach all or part of that object to other objects that
need it. need it.
Figure 15 shows a portion of the SUPAPolicyMetadata hierarchy. Figure 15 shows a portion of the SUPAPolicyMetadata hierarchy.
A A
+--------------------+ +--------------------+
| | HasSUPAMetadataDecorator | | SUPAHasMetadataDecorator
| SUPAPolicyMetadata +-------------------+ | SUPAPolicyMetadata +-------------------+
| | 1..n | | | 1..n |
+---------+----------+ | +---------+----------+ |
I | I |
I | I |
I | I |
+-------------+-----------------+ | +-------------+-----------------+ |
| | | | | |
C | | / \ C | | / \
+---------+------------------+ | A +---------+------------------+ | A
skipping to change at page 48, line 5 skipping to change at page 48, line 5
4.5.1. Policy Grouping 4.5.1. Policy Grouping
This section will be completed in the next revision of this This section will be completed in the next revision of this
document. document.
4.5.2. Policy Rule Nesting 4.5.2. Policy Rule Nesting
This section will be completed in the next revision of this This section will be completed in the next revision of this
document. 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 16; section numbers
are appended after each class. 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 (5.2)
| | | |
| +---SUPAPolicyStructure (5.3) | +---SUPAPolicyStructure (5.3)
| | | |
| +---SUPAPolicyComponentStructure (5.4) | +---SUPAPolicyComponentStructure (5.4)
skipping to change at page 50, line 31 skipping to change at page 50, line 31
5.2.1.1. Object Identifiers 5.2.1.1. Object Identifiers
This document defines two class attributes in SUPAPolicyObject, This document defines two class attributes in SUPAPolicyObject,
called supaPolObjIDContent and supaPolObjIDEncoding, that together called supaPolObjIDContent and supaPolObjIDEncoding, that together
define a unique object ID. This enables all class instances to be define a unique object ID. This enables all class instances to be
uniquely identified. uniquely identified.
One of the goals of SUPA is to be able to generate different data One of the goals of SUPA is to be able to generate different data
models that support different types of protocols and repositories. models that support different types of protocols and repositories.
This means that the notion of an object ID must be generic. It is This means that the notion of an object ID must be generic. It is
inappropriate to use data modeling concepts, such as keys, GUIDs, inappropriate to use data modeling concepts, such as keys, Globally
UUIDs, FQDNs, URIs, and other similar mechanisms, to define the Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs),
structure of an information model. Therefore, a synthetic object Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names
ID is defined using these two attributes. This can be used to (FQPNs), Uniform Resource Identifiers (URIs), and other similar
facilitate mapping to different data model object schemes, such mechanisms, to define the structure of an information model.
as those depending on URIs, FQDNs, UUIDs, primary key-foreign key Therefore, a synthetic object ID is defined using these two class
relationships, UUIDs, and others can all be accommodated. attributes. This can be used to facilitate mapping to different data
model object schemes.
The two attributes work together, with the supaPolObjIDContent The two attributes work together, with the supaPolObjIDContent
attribute defining the content of the object ID and the attribute defining the content of the object ID and the
supaPolObjIDEncoding attribute defining how to interpret the supaPolObjIDEncoding attribute defining how to interpret the
content. These two attributes form a tuple, and together enable content. These two attributes form a tuple, and together enable
a machine to understand the syntax and value of an object a machine to understand the syntax and value of an object
identifier for the object instance of this class. identifier for the object instance of this class.
Similarly, all SUPA classes are attributes are both uniquely Similarly, all SUPA classes are attributes are both uniquely
named as well as prepended with the prefixes "SUPA" and "supa", named as well as prepended with the prefixes "SUPA" and "supa",
skipping to change at page 51, line 35 skipping to change at page 51, line 35
this class. The supaPolObjIDEncoding attribute is mapped to the this class. The supaPolObjIDEncoding attribute is mapped to the
following values: following values:
0: undefined 0: undefined
1: GUID 1: GUID
2: UUID 2: UUID
3: primary key 3: primary key
4: foreign key 4: foreign key
5: URI 5: URI
6: FQDN 6: FQDN
7: FQPN
The value 0 may be used to initialize the system, or to signal The value 0 may be used to initialize the system, or to signal
that there is a problem with this particular SUPAPolicyObject. that there is a problem with this particular SUPAPolicyObject.
5.2.1.4. The Attribute "supaPolicyDescription" 5.2.1.4. The Attribute "supaPolicyDescription"
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 object. textual description of this object.
5.2.1.5. The Attribute "supaPolicyName" 5.2.1.5. The Attribute "supaPolicyName"
skipping to change at page 52, line 24 skipping to change at page 52, line 24
SUPAPolicyObject. This aggregation is defined in section SUPAPolicyObject. This aggregation is defined in section
5.16.2. 5.16.2.
5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail" 5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail"
This is a mandatory concrete association class that defines the This is a mandatory concrete association class that defines the
semantics of the SUPAPolicyMetadata aggregation. This enables the semantics of the SUPAPolicyMetadata aggregation. This enables the
attributes and relationships of the SUPAPolicyMetadataDetail class attributes and relationships of the SUPAPolicyMetadataDetail class
to be used to constrain which SUPAPolicyMetadata objects can be to be used to constrain which SUPAPolicyMetadata objects can be
aggregated by this particular SUPAPolicyObject instance. This aggregated by this particular SUPAPolicyObject instance. This
association class is defined in Section 5.16.3. association class is defined in Section 5.16.2.2.
5.3. The Abstract Class "SUPAPolicyStructure" 5.3. The Abstract Class "SUPAPolicyStructure"
This is a mandatory abstract class that is used to represent the This is a mandatory abstract class that is used to represent the
structure of a SUPAPolicy. This class (and all of its subclasses) structure of a SUPAPolicy. This class (and all of its subclasses)
is a type of PolicyContainer. SUPAPolicyStructure was abstracted is a type of PolicyContainer. SUPAPolicyStructure was abstracted
from DEN-ng [2], and a version of this class is in the process of from DEN-ng [2], and a version of this class is in the process of
being added to [5]. However, the version in [5] differs being added to [5]. However, the version in [5] differs
significantly. First, the class and relationship definitions ared significantly. First, the class and relationship definitions ared
different. Second, [5] uses the composite pattern. Neither of different. Second, [5] uses the composite pattern. Neither of
skipping to change at page 53, line 5 skipping to change at page 53, line 5
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.
5.3.1. SUPAPolicyStructure Attributes 5.3.1. SUPAPolicyStructure Attributes
The following subsections define the attributes of the The following subsections define the attributes of the
SUPAPolicyStructure class. SUPAPolicyStructure class.
The SUPAPolicyStructure class has a number of attributes that have The SUPAPolicyStructure class has a number of attributes that have
no counterpart in the SUPAPolicyComponentStructure class. This is no counterpart in the SUPAPolicyComponentStructure class. This is
because these attributes are only appropriate at the level of a because these attributes are only appropriate at the level of a
policy rule, not at the level of a policy component. policy rule, not at the level of a policy component.
Care must be taken in adding attributes to this class, Care must be taken in adding attributes to this class,
skipping to change at page 55, line 41 skipping to change at page 55, line 41
as to enforce deontic and alethic logic. as to enforce deontic and alethic logic.
The multiplicity of this aggregation is 0..n - 0..n. This means The multiplicity of this aggregation is 0..n - 0..n. This means
that it is an optional aggregation; zero or more SUPAPolicySource that it is an optional aggregation; zero or more SUPAPolicySource
objects may be aggregated by this SUPAPolicyStructure object, objects may be aggregated by this SUPAPolicyStructure object,
and zero or more SUPAPolicyStructure objects may aggregate this and zero or more SUPAPolicyStructure objects may aggregate this
particular SUPAPolicySource object. particular SUPAPolicySource object.
5.3.2.2. The Association Class "SUPAHasPolicySourceDetail" 5.3.2.2. The Association Class "SUPAHasPolicySourceDetail"
This is an optional association class, and defines the semantics This is an optional concrete association class, and defines the
of the SUPAHasPolicySource aggregation. The attributes and semantics of the SUPAHasPolicySource aggregation. The attributes and
relationships of this class can be used to define which relationships of this class can be used to define which
SUPAPolicySource objects can be attached to which particular set SUPAPolicySource objects can be attached to which particular set
of SUPAPolicyStructure objects. of SUPAPolicyStructure objects.
5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated"
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 SUPAPolicySource object has been attribute is true, then this SUPAPolicySource object has been
authenticated by this particular SUPAPolicyStructure object. authenticated by this particular SUPAPolicyStructure object.
skipping to change at page 56, line 29 skipping to change at page 56, line 29
that will be affected by the execution of one or more SUPAPolicies. that will be affected by the execution of one or more SUPAPolicies.
The multiplicity of this aggregation is 0..n - 0..n. This means The multiplicity of this aggregation is 0..n - 0..n. This means
that it is an optional aggregation; zero or more SUPAPolicyTarget that it is an optional aggregation; zero or more SUPAPolicyTarget
objects may be aggregated by this SUPAPolicyStructure object, objects may be aggregated by this SUPAPolicyStructure object,
and zero or more SUPAPolicyStructure objects may aggregate this and zero or more SUPAPolicyStructure objects may aggregate this
particular SUPAPolicyTarget object. particular SUPAPolicyTarget object.
5.3.2.4. The Association Class "SUPAHasPolicyTargetDetail" 5.3.2.4. The Association Class "SUPAHasPolicyTargetDetail"
This is an optional association class, and defines the semantics This is an optional concrete association class, and defines the
of the SUPAPolicyTargetOf aggregation. The attributes and semantics of the SUPAPolicyTargetOf aggregation. The attributes and
relationships of this class can be used to define which relationships of this class can be used to define which
SUPAPolicyTargets can be attached to which particular set of SUPAPolicyTargets can be attached to which particular set of
SUPAPolicyStructure objects. SUPAPolicyStructure objects.
5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated"
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 SUPAPolicyTarget object has been attribute is true, then this SUPAPolicyTarget object has been
authenticated by this particular SUPAPolicyStructure object. authenticated by this particular SUPAPolicyStructure object.
skipping to change at page 58, line 11 skipping to change at page 58, line 11
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: undefined 0: undefined
1: String 1: String
2: GUID 2: GUID
3: UUID 3: UUID
4: URI 4: URI
5: FQDN 5: FQDN
6: FQPN
5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]"
This is an optional array of string attributes that identifies the This is an optional array of string attributes that identifies the
set of policy actions to take if the SUPAPolicyStructure object set of policy actions to take if the SUPAPolicyStructure object
that owns this association failed to execute properly. The that owns this association failed to execute properly. The
interpretation of this string attribute is defined by the interpretation of this string attribute is defined by the
supaPolExecFailTakeActionEncoding class attribute. The association supaPolExecFailTakeActionEncoding class attribute. The association
defines the SUPAPolicyStructure that contains the set of policy defines the SUPAPolicyStructure that contains the set of policy
actions to execute, and this attribute defines which of these actions to execute, and this attribute defines which of these
skipping to change at page 58, line 49 skipping to change at page 58, line 50
more SUPAPolicyStructure object instances at a given time. Thus, more SUPAPolicyStructure object instances at a given time. Thus,
the multiplicity of this aggregation is defined as 0..1 on the the multiplicity of this aggregation is defined as 0..1 on the
aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the
part (i.e., the SUPAPolicyClause side). This means that at part (i.e., the SUPAPolicyClause side). This means that at
least one SUPAPolicyClause MUST be aggregated by this least one SUPAPolicyClause MUST be aggregated by this
SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may
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 association class, and defines the semantics This is an optional abstract association class, and defines the
of the SUPAHasPolicyClause aggregation. The attributes and/or semantics of the SUPAHasPolicyClause aggregation. The attributes
relationships of this association class can be used to determine and/or relationships of this association class can be used to
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. 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 that 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. However, all of these are used in at least structural components. However, all of these are used in at least
skipping to change at page 60, line 6 skipping to change at page 60, line 6
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). but is typically used by SUPAECAPolicyRule objects).
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 SUPAPolicyComponentDecorator, which
was shown in Figure 10. These four subclasses provide four was shown in Figure 10. These four subclasses provide four
different ways to construct a SUPAPolicyClause: different ways to construct a SUPAPolicyClause:
1) SUPAPolicyTerm, which enables constructing a {variable, 1) SUPAPolicyTerm, which enables constructing a {variable,
operator, value} expression for building DUPAPolicyClauses operator, value} expression for building SUPAPolicyClauses
2) SUPAEncodedClause, which enables policy clauses to be 2) SUPAEncodedClause, which enables policy clauses 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) SUPAPolicyCollection, which defines a collection of objects 3) SUPAPolicyCollection, which defines a collection of objects
that requires further processing by the policy management that requires further processing by the policy management
system in order to be made into a SUPAPolicyClause system in order to be made into a SUPAPolicyClause
4) SUPAECAComponent, which enables policy clauses to be formed 4) SUPAECAComponent, which enables policy clauses to be formed
using (reusable) Event, Condition, and/or Action objects using (reusable) Event, Condition, and/or Action objects
SUPAPolicyClauses are aggregated by a SUPAPolicyStructure SUPAPolicyClauses are aggregated by a SUPAPolicyStructure
object, which enables all types of SUPAPolicies to uniformly be object, which enables all types of SUPAPolicies to uniformly be
skipping to change at page 60, line 43 skipping to change at page 60, line 43
0: Unknown (an error state) 0: Unknown (an error state)
1: Completed (i.e., successfully executed, but now idle) 1: Completed (i.e., successfully executed, but now idle)
2: Working (i.e., in use and no errors reported) 2: Working (i.e., in use and no errors reported)
3: Not Working (i.e., in use, but errors have been reported) 3: Not Working (i.e., in use, but errors have been reported)
4: Available (i.e., could be used, but currently isn't) 4: Available (i.e., could be used, but currently isn't)
5: In Test (i.e., cannot be used as part of an OAM&P policy) 5: In Test (i.e., cannot be used as part of an OAM&P policy)
6: Disabled (i.e., not available for use) 6: Disabled (i.e., not available for use)
Value 0 denotes an error that prevents this SUPAPolicyClause Value 0 denotes an error that prevents this SUPAPolicyClause
from being used. Value 1 means that this SUPAPolicyClause has from being used. Value 1 means that this SUPAPolicyClause has
successfully finished execution, and is now idle. Value 2 means successfully finished execution, and is now idle and available.
that this SUPAPolicyClause is in use; in addition, this Value 2 means that this SUPAPolicyClause is in use; in addition,
SUPAPolicyClause is working correctly. Value 3 is the same as this SUPAPolicyClause is working correctly. Value 3 is the same as
value 2, except that this SUPAPolicyClause is not working value 2, except that this SUPAPolicyClause is not working
correctly. Value 4 means that this SUPAPolicyClause is available, correctly. Value 4 means that this SUPAPolicyClause is available,
but not currently in use. Value 5 means that this SUPAPolicyClause but not currently in use. Value 5 means that this SUPAPolicyClause
is in a special test state. A test state signifies that it SHOULD is in a special test state. A test state signifies that it SHOULD
NOT be used to evaluate OAM&P policies. A value of 6 means that NOT be used to evaluate OAM&P policies. A value of 6 means that
this SUPAPolicyClause is unavailable for use. this SUPAPolicyClause is unavailable for use.
5.5.2. SUPAPolicyClause Relationships 5.5.2. SUPAPolicyClause Relationships
SUPAPolicyClause participates in a single relationship, SUPAPolicyClause participates in a single relationship,
skipping to change at page 61, line 49 skipping to change at page 61, line 49
This is a mandatory string attribute, and defines the content of This is a mandatory string attribute, and defines the content of
this clause. It works with another class attribute, called this clause. It works with another class attribute, called
supaEncodedClauseEncoding, which defines how to interpret the supaEncodedClauseEncoding, which defines how to interpret the
value of this attribute (e.g., as a string or reference). These value of this attribute (e.g., as a string or reference). These
two attributes form a tuple, and together enable a machine to two attributes form a tuple, and together enable a machine to
understand the syntax and value of this object instance. understand the syntax and value of this object instance.
5.6.1.2. The Attribute "supaEncodedClauseEncoding" 5.6.1.2. The Attribute "supaEncodedClauseEncoding"
This is a mandatory integer attribute, and defines how to This is a mandatory non-negative integer attribute, and defines
interpret the value of this encoded clause. It works with another how to interpret the value of this encoded clause. It works with
class attribute, called supaEncodedClauseContent, which defines another class attribute (supaEncodedClauseContent), which defines
the content of the encoded clause. These two attributes form a the content of the encoded clause. These two attributes form a
tuple, and together enable a machine to understand the syntax and tuple, and together enable a machine to understand the syntax and
value of the encoded clause for the object instance of this class. value of the encoded clause for the object instance of this class.
Values include: Values include:
0: undefined 0: undefined
1: String 1: String
2: GUID 2: GUID
3: UUID 3: UUID
4: URI 4: URI
5: FQDN 5: FQDN
6: FQPN
5.6.1.3. The Attribute "supaEncodedClauseResponse" 5.6.1.3. The Attribute "supaEncodedClauseLanguage"
This is mandatory non-negative integer attribute, and defines
the type of language used in this encoded clause. Values include:
0: undefined
1: Text
2: YANG
3: XML
4: CLI
5: TL1
5.6.1.4. The Attribute "supaEncodedClauseLang[0..n]"
This is an optional array of string attribute that contains
descriptive information about the type of language used in the
supaEncodedClauseLanguage class attribute. Text is in comma
separated value (i.e., vendorName, vendorVersion) format.
5.6.1.5. The Attribute "supaEncodedClauseResponse"
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.
5.6.2. SUPAEncodedClause Relationships 5.6.2. SUPAEncodedClause Relationships
SUPAPolicyClause participates in a single inherited relationship, SUPAPolicyClause participates in a single inherited relationship,
skipping to change at page 63, line 19 skipping to change at page 63, line 43
the SUPAPolicyComponentDecorator object has an instance variable the SUPAPolicyComponentDecorator object has an instance variable
that holds a reference to a SUPAPolicyClause object. Since the that holds a reference to a SUPAPolicyClause object. Since the
SUPAPolicyComponentDecorator object has the same interface as the SUPAPolicyComponentDecorator object has the same interface as the
SUPAPolicyClause object, the SUPAPolicyComponentDecorator object SUPAPolicyClause object, the SUPAPolicyComponentDecorator object
(and all of its subclasses) are transparent to clients of the (and all of its subclasses) are transparent to clients of the
SUPAPolicyClause object (and its subclasses). This means that SUPAPolicyClause object (and its subclasses). This means that
SUPAPolicyComponentDecorator object instances can add attributes SUPAPolicyComponentDecorator object instances can add attributes
and/or methods to those of the concrete instance of the chosen and/or methods to those of the concrete instance of the chosen
subclass of SUPAPolicyClause. subclass of SUPAPolicyClause.
Figure 19 shows how this is done for methods. 19a shows the Figure 20 shows how this is done for methods. 20a shows the
initial object to be wrapped; 19b shows SUPAPolicyCollection initial object to be wrapped; 20b shows SUPAPolicyCollection
wrapping SUPAEncodedClause; 19c shows SUPAGenericDecoratedComponent wrapping SUPAEncodedClause; 20c shows SUPAGenericDecoratedComponent
wrapping SUPAPolicyCollection. wrapping SUPAPolicyCollection.
+-------------------+ +-------------------+
| SUPAEncodedClause | | SUPAEncodedClause |
| eval() | | eval() |
+-------------------+ +-------------------+
(a) Initial Object (a) Initial Object
===> ===>
+------------------------+ +------------------------+
skipping to change at page 64, line 5 skipping to change at page 64, line 39
| | +-------------------+ | | | | +-------------------+ | |
| | | SUPAEncodedClause | | | | | | SUPAEncodedClause | | |
| | | eval() | | | | | | eval() | | |
| | +-------------------+ | | | | +-------------------+ | |
| +-----------------------+ | | +-----------------------+ |
+--------------------------------+ +--------------------------------+
(c) SUPAGenericDecoratedComponent "wraps" SUPAPolicyCollection (c) SUPAGenericDecoratedComponent "wraps" SUPAPolicyCollection
Figure 20. Conceptual Depiction of eval() Decorated Method Figure 20. Conceptual Depiction of eval() Decorated Method
When eval() is called in the outermost object When eval() is called in the outermost object
(SUPAGenericDecoratedComponent), it delegates to the eval() method (SUPAGenericDecoratedComponent), it delegates to the eval() method
of SUPAPolicyCollection, which in turn delegates to the eval() of SUPAPolicyCollection, which in turn delegates to the eval()
method of SUPAEncodedClause. This method executes and returns the method of SUPAEncodedClause. This method executes and returns the
results to SUPAPolicyCollection, which executes and returns the results to SUPAPolicyCollection, which executes and returns the
results to SUPAGenericDecoratedComponent, which executes and returns results to SUPAGenericDecoratedComponent, which executes and returns
the final result. the final result.
5.7.2. SUPAPolicyComponentDecorator Attributes 5.7.2. SUPAPolicyComponentDecorator 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 SUPAPolicyComponentDecorator that is wrapping the
concrete subclass of SUPAPolicyClause. This is different concrete subclass of SUPAPolicyClause.
than the use of similar attributes defined in the
SUPAHasDecoratedPolicyComponentDetail association class (which This is different than the use of similar attributes defined in
the SUPAHasDecoratedPolicyComponentDetail association class (which
are used to constrain the relationship between the concrete are used to constrain the relationship between the concrete
subclass of SUPAPolicyClause and the concrete subclass of the subclass of SUPAPolicyClause and the concrete subclass of the
SUPAHasDecoratedPolicyComponent object that is wrapping it). SUPAPolicyComponentDecorator object that is wrapping it).
Note that [2] does not define any attributes for this class. Note that [2] does not define any attributes for this class.
5.7.2.1. The Attribute "supaPolCompConstraintEncoding" 5.7.2.1. The Attribute "supaPolCompConstraintEncoding"
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: undefined 0: undefined
1: OCL 2.4 1: OCL 2.4
2: OCL 2.x 2: OCL 2.x
3: OCL 1.x 3: OCL 1.x
4: QVT 1.2 - Relations Language 4: QVT 1.2 - Relations Language
5: QVT 1.2 - Operational language 5: QVT 1.2 - Operational language
6: Alloy 6: Alloy
7: English text
Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the
latest version as of this writing). QVT defines a set of languages latest version as of this writing). QVT defines a set of languages
(the two most powerful and useful are defined by enumerations 4 (the two most powerful and useful are defined by enumerations 4
and 5). Alloy is a language for describing constraints, and uses a and 5). Alloy is a language for describing constraints, and uses a
SAT solver to guarantee correctness. SAT solver to guarantee correctness. Note that enumeration 7
(English text) is not recommended (since it is informal, and hence,
not verifiable), but included for completeness.
5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" 5.7.2.2. The Attribute "supaAPolCompConstraint[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]. possible in [RFC3460].
Note: [0..n] means that this is a multi-valued property that may Note: [0..n] means that this is a multi-valued property that may
have zero or more attributes. have zero or more attributes.
5.7.3. SUPAPolicyComponentDecorator Relationships 5.7.3. SUPAPolicyComponentDecorator Relationships
One relationship is currently defined for this class, which is One relationship is currently defined for this class, which is
described in the following subsection. described in the following subsection.
5.7.3.1. The Aggregation "SUPAHasDecoratedPolicyComponent" 5.7.3.1. The Aggregation "SUPAHasDecoratedPolicyComponent"
skipping to change at page 65, line 50 skipping to change at page 66, line 45
how to interpret each string in the supaDecoratedConstraint class how to interpret each string in the supaDecoratedConstraint class
attribute. Values include: attribute. Values include:
0: undefined 0: undefined
1: OCL 2.4 1: OCL 2.4
2: OCL 2.x 2: OCL 2.x
3: OCL 1.x 3: OCL 1.x
4: QVT 1.2 - Relations Language 4: QVT 1.2 - Relations Language
5: QVT 1.2 - Operational language 5: QVT 1.2 - Operational language
6: Alloy 6: Alloy
7: English text
Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the
latest version as of this writing). QVT defines a set of languages latest version as of this writing). QVT defines a set of languages
(the two most powerful and useful are defined by enumerations 4 (the two most powerful and useful are defined by enumerations 4
and 5). Alloy is a language for describing constraints, and uses a and 5). Alloy is a language for describing constraints, and uses a
SAT solver to guarantee correctness. SAT solver to guarantee correctness. Note that enumeration 7
(English text) is not recommended (since it is informal, and hence,
not verifiable), but included for completeness.
5.7.3.2.2. The Attribute "supaDecoratedConstraint[0..n]" 5.7.3.2.2. The Attribute "supaDecoratedConstraint[0..n]"
This is a mandatory array of string attributes. Its purpose is to This is a mandatory array of string attributes. Its purpose is to
collect a set of constraints to be applied to a decorated object. collect a set of constraints to be applied to a decorated object.
The interpretation of each constraint in the array is defined in The interpretation of each constraint in the array is defined in
the supaDecoratedConstraintsEncoding class attribute. the supaDecoratedConstraintsEncoding class attribute.
Note: [0..n] means that this is a multi-valued property that may Note: [0..n] means that this is a multi-valued property that may
have zero or more attributes. have zero or more attributes.
skipping to change at page 68, line 48 skipping to change at page 69, line 48
section 5.7.3. 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.
Note that this is not possible in previous designs ([RFC3460, [4], This is not possible in previous designs ([RFC3460, [4], and [6]).
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 SUPAPolicyRule 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
skipping to change at page 69, line 39 skipping to change at page 70, line 39
SUPAPolicyVariable defines one attribute, as described below. SUPAPolicyVariable defines one attribute, as described below.
5.9.2.1. The Attribute "supaPolVarName" 5.9.2.1. The Attribute "supaPolVarName"
This is an optional string attribute that contains the name of This is an optional string attribute that contains the name of
this SUPAPolicyVariable. This variable name forms part of the this SUPAPolicyVariable. This variable name forms part of the
{variable, operator, value} canonical form of a SUPAPolicyClause. {variable, operator, value} canonical form of a SUPAPolicyClause.
5.9.3. SUPAPolicyVariable Relationships 5.9.3. SUPAPolicyVariable Relationships
Currently, no relationships are defiend for the SUPAPolicyVariable Currently, no relationships are defined for the SUPAPolicyVariable
class (note that the decorator pattern obviates the need for class (note that the decorator pattern obviates the need for
relationships such as those in [RFC3460] and [6]). relationships such as those in [RFC3460] and [6]).
SUPAPolicyVariable, and its subclasses, inherit the SUPAPolicyVariable, and its subclasses, inherit the
SUPAHasDecoratedPolicyComponent aggregation, which was defined in SUPAHasDecoratedPolicyComponent aggregation, which was defined in
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.
skipping to change at page 70, line 31 skipping to change at page 71, line 31
1: Greater than 1: Greater than
2: Greater than or equal to 2: Greater than or equal to
3: Less than 3: Less than
4: Less than or equal to 4: Less than or equal to
5: Equal to 5: Equal to
6: Not equal to 6: Not equal to
7: IN 7: IN
8: NOT IN 8: NOT IN
9: SET 9: SET
10: CLEAR 10: CLEAR
11: BETWEEN 11: BETWEEN (inclusive)
Note that 0 is an unacceptable value. Its purpose is to support Note that 0 is an unacceptable value. Its purpose is to support
dynamically building a SUPAPolicyClause by enabling the dynamically building a SUPAPolicyClause by enabling the
application to set the value of this attribute to a standard application to set the value of this attribute to a standard
default value if the real value is not yet known. default value if the real value is not yet known.
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 defiend for the SUPAPolicyOperator Currently, no relationships are defined for the SUPAPolicyOperator
class (note that the decorator pattern obviates the need for class (note that the decorator pattern obviates the need for
relationships such as those in [6]). SUPAPolicyOperator, and its relationships such as those in [6]). SUPAPolicyOperator, and its
subclasses, inherit the SUPAHasDecoratedPolicyComponent subclasses, inherit the SUPAHasDecoratedPolicyComponent
aggregation, which was defined in section 5.7.3. aggregation, which was defined in section 5.7.3.
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
SUPAPolicyOperator when used in a SUPAPolicyClause. SUPAPolicyOperator when used in a SUPAPolicyClause.
5.11. The Concrete Class "SUPAPolicyValue" 5.11. The Concrete Class "SUPAPolicyValue"
skipping to change at page 72, line 21 skipping to change at page 73, line 21
0: Undefined 0: Undefined
1: String 1: String
2: Integer 2: Integer
3: Boolean 3: Boolean
4: Floating Point 4: Floating Point
5: DateTime 5: DateTime
6: GUID 6: GUID
7: UUID 7: UUID
8: URI 8: URI
9: FQDN 9: FQDN
10: NULL 10: FQPN
11: NULL
A string is a sequence of zero or more characters. An Integer is A string is a sequence of zero or more characters. An Integer is
a whole number (e.g., it has no fractional part). A Boolean a whole number (e.g., it has no fractional part). A Boolean
represents the values TRUE and FALSE. A floating point number may represents the values TRUE and FALSE. A floating point number may
contain fractional values, as well as an exponent. A DateTime contain fractional values, as well as an exponent. A DateTime
represents a value that has a date and/or a time component (as in represents a value that has a date and/or a time component (as in
the Java or Python libraries). A NULL explicitly models the lack the Java or Python libraries). A NULL explicitly models the lack
of a value. of a value.
5.11.3. SUPAPolicyValue Relationships 5.11.3. SUPAPolicyValue Relationships
Currently, no relationships are defiend for the SUPAPolicyValue Currently, no relationships are defined for the SUPAPolicyValue
class (note that the decorator pattern obviates the need for class (note that the decorator pattern obviates the need for
relationships such as those in [6]). SUPAPolicyValue, and its relationships such as those in [6]). SUPAPolicyValue, and its
subclasses, inherit the SUPAHasDecoratedPolicyComponent subclasses, inherit the SUPAHasDecoratedPolicyComponent
aggregation, which was defined in section 5.7.3. aggregation, which was defined in section 5.7.3.
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
SUPAPolicyValue when used in a SUPAPolicyClause. SUPAPolicyValue when used in a SUPAPolicyClause.
5.12. The Concrete Class "SUPAGenericDecoratedComponent" 5.12. The Concrete Class "SUPAGenericDecoratedComponent"
skipping to change at page 73, line 34 skipping to change at page 74, line 34
0: undefined 0: undefined
1: String 1: String
2: Integer 2: Integer
3: Boolean 3: Boolean
4: Floating Point 4: Floating Point
5: DateTime 5: DateTime
6: GUID 6: GUID
7: UUID 7: UUID
8: URI 8: URI
9: FQDN 9: FQDN
10: NULL 10: FQPN
11: NULL
A string is a sequence of zero or more characters. An Integer is A string is a sequence of zero or more characters. An Integer is
a whole number (e.g., it has no fractional part). A Boolean a whole number (e.g., it has no fractional part). A Boolean
represents the values TRUE and FALSE. A floating point number may represents the values TRUE and FALSE. A floating point number may
contain fractional values, as well as an exponent. A DateTime contain fractional values, as well as an exponent. A DateTime
represents a value that has a date and/or a time component (as in represents a value that has a date and/or a time component (as in
the Java or Python libraries). A NULL explicitly models the lack the Java or Python libraries). A NULL explicitly models the lack
of a value. of a value.
5.12.2. SUPAGenericDecoratedComponent Relationships 5.12.2. SUPAGenericDecoratedComponent Relationships
skipping to change at page 76, line 17 skipping to change at page 77, line 17
This is an optional non-negative enumerated integer that defines This is an optional non-negative enumerated integer that defines
the type of collection that this instance is. Values include: the type of collection that this instance is. Values include:
0: undefined 0: undefined
1: set 1: set
2: bag (e.g., multi-set) 2: bag (e.g., multi-set)
3: dictionary (e.g., associative array) 3: dictionary (e.g., associative array)
A set is an unordered collection of elements that MUST NOT have A set is an unordered collection of elements that MUST NOT have
duplicates. A bag is an unordered collection of elements; it MAY duplicates. A bag is an unordered collection of elements; it MAY
also have duplicates. A dictonary is a table that associates a also have duplicates. A dictionary is a table that associates a
key with a value. key with a value.
Sets have a number of important functions, including: Sets have a number of important functions, including:
o membership: returns TRUE if the element being tested is o membership: returns TRUE if the element being tested is
in the set, and FALSE otherwise in the set, and FALSE otherwise
o subset: returns TRUE if all elements in the first set o subset: returns TRUE if all elements in the first set
are also in the second set are also in the second set
o union: returns all elements from both sets with no o union: returns all elements from both sets with no
duplicates duplicates
skipping to change at page 77, line 7 skipping to change at page 78, line 7
key and a value is called an item. The format of an item is key and a value is called an item. The format of an item is
defined as one element (the key) followed by a colon followed defined as one element (the key) followed by a colon followed
by a second element (the value). Each item in a set of items is by a second element (the value). Each item in a set of items is
separated by a comma. Keys MUST NOT be NULL; values MAY be NULL. separated by a comma. Keys MUST NOT be NULL; values MAY be NULL.
An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}. An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}.
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 defiend 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 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 12.
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
skipping to change at page 80, line 10 skipping to change at page 81, line 10
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: undefined 0: undefined
1: GUID 1: GUID
2: UUID 2: UUID
3: URI 3: URI
4: FQDN 4: FQDN
5: FQPN
5.16.1.4. The Attribute "supaPolMetadataName" 5.16.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.16.2. SUPAPolicyMetadata Relationships
SUPAPolicyMetadata participates in a single aggregation, which is SUPAPolicyMetadata participates in a single aggregation, which is
defined in the following subsections. defined in the following subsections.
5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata"
This is an optional 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. It is recommended that this aggregation be used
as part of a conformant implementation. 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. The semantics of this aggregation are implemented using
the SUPAHasPolicyMetadataDetail association class. the SUPAHasPolicyMetadataDetail association class.
5.16.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail" 5.16.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail"
This is an optional abstract 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. It is recommended that this
association class be used as part of a conformant implementation. association class be used as part of a conformant implementation.
5.16.2.2.1. The Attribute "supaPolMetadataIsApplicable" 5.16.2.2.1. The Attribute "supaPolMetadataIsApplicable"
skipping to change at page 81, line 18 skipping to change at page 82, line 18
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: undefined 0: undefined
1: OCL 2.4 1: OCL 2.4
2: OCL 2.x 2: OCL 2.x
3: OCL 1.x 3: OCL 1.x
4: QVT 1.2 - Relations Language 4: QVT 1.2 - Relations Language
5: QVT 1.2 - Operational language 5: QVT 1.2 - Operational language
6: Alloy 6: Alloy
7: English text
Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the
latest version as of this writing). QVT defines a set of languages latest version as of this writing). QVT defines a set of languages
(the two most powerful and useful are defined by enumerations 4 (the two most powerful and useful are defined by enumerations 4
and 5). Alloy is a language for describing constraints, and uses a and 5). Alloy is a language for describing constraints, and uses a
SAT solver to guarantee correctness. SAT solver to guarantee correctness. Note that enumeration 7
(English text) is not recommended (since it is informal, and hence,
not verifiable), but 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.16.2.2.3. 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
skipping to change at page 82, line 28 skipping to change at page 83, line 28
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.17.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.16.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 HasSUPAMetadataDecorator aggregation; see section 5.18.2. in the SUPAHasMetadataDecorator aggregation; see section 5.18.2.
5.18. The Abstract Class "SUPAPolicyMetadataDecorator" 5.18. 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 5.7.1.) 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.18.1. SUPAPolicyMetadataDecorator Attributes
Currently, no attributes are defined for the Currently, no attributes are defined for the
SUPAPolicyMetadataDecorator class. SUPAPolicyMetadataDecorator class.
5.18.2. SUPAPolicyMetadataDecorator Relationships 5.18.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.16.2. It also defines a single aggregation,
HasSUPAMetadataDecorator, 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 "HasSUPAMetadataDecorator" 5.18.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 HasSUPAMetadataDecoratorDetail 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
HasSUPAMetadataDecoratorDetail association class. SUPAHasMetadataDecoratorDetail association class.
5.18.2.2. The Association Class "HasSUPAMetadataDecoratorDetail" 5.18.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 HasSUPAMetadataDecorator 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.
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 Attributes for this association class will be defined in a future
version of this document. version of this document.
skipping to change at page 85, line 20 skipping to change at page 86, line 20
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: Undefined 0: Undefined
1: URI 1: URI
2: GUID 2: GUID
3: UUID 3: UUID
4: FQDN 4: FQDN
5: FQPN
5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" 5.20. 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.20.1. SUPAPolicyVersionMetadataDef Attributes
Version information is defined in a generic format as follows: Version information is defined in a generic format based on the
Semantic Versioning Specification [18] as follows:
<major>.<minor>.<relType>.<relTypeNum> <major>.<minor>.<patch>[<pre-release>][<build-metadata>]
where the first three components (major, minor, and patch) MUST be
present, and the latter two components (pre-release and build-
metadata) MAY be present. A version number MUST take the form
<major>.<minor>.<patch>, where <major>, <minor>, and <patch> are
each non-negative integers that MUST NOT contain leading zeros.
In addition, the value of each of these three elements MUST
increase numerically.
In this approach: In this approach:
o supaVersionMajor denotes a major new release o supaVersionMajor denotes a new release; this number MUST be
o supaVersionMinor denotes an incremental release, that adds new incremented when either changes are introduced that are not
features and/or bug fixes to a major release backwards-compatible, and/or new functionality not previously
o supaVersionRelType denotes the type of release (e.g., internal, present is introduced
alpha, production)
o supaVersionRelTypeNum denotes an incremental release of ability
particular type
Currently, the SUPAPolicyVersionMetadataDef class defines three o supaVersionMinor denotes a minor release; this number MUST be
incremented when new features and/or bug fixes to a major
release that are backwards-compatible are introduced, and/or
if any features are marked as deprecated
o supaVersionPatch denotes a version that consists ONLY of bug
fixes, and MUST be incremented when these bug fixes are Not
backwards-compatible
When multiple versions exist, the following rules define their
precedence:
1. Precedence MUST be calculated by separating the version into
major, minor, patch, and pre-release identifiers, in that
order. Note that build-metadata is NOT used to calculated
precedence.
2. Precedence is determined by the first difference when
comparing each of these identifiers, from left to right,
as follows:
a. Major, minor, and patch versions are always compared
numerically (e.g., 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1)
b. When major, minor, and patch are equal, a pre-release
version has LOWER precedence than a normal version
(e.g., 1.0.0-alpha < 1.0.0)
c. Precedence for two pre-release versions with the same
major, minor, and patch version MUST be determined by
comparing each dot separated identifier from left to
right until a difference is found as follows:
- identifiers consisting only of digits are compared
numerically and identifiers with letters and/or
hyphens are compared lexically in ASCII sort order
- Numeric identifiers always have lower precedence
than non-numeric identifiers
- A larger set of pre-release fields has a higher
precedence than a smaller set, if all of the
preceding identifiers are equal
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.
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.20.1.1. The Attribute "supaVersionMajor"
This is an optional string attribute, and contains a string This is a mandatory string attribute, and contains a string
(typically representing an integer) indicating a significant representation of an integer that is greater than or equal to zero.
increase in functionality is present in this version. It indicates that a significant increase in functionality is
present in this version. It MAY also indicate that this version has
changes that are NOT backwards-compatible; this MAY be denoted in
the supaVersionBuildMetadata class attribute.
The special string "0.1.0" is for initial development that MUST
NOT be considered stable. Improvements to this initial version,
before they are released to the public, are denoted by incrementing
the minor and patch version numbers.
The major version X (i.e., X.y.z, where X > 0) MUST be incremented
if any backwards incompatible changes are introduced. It MAY
include minor and patch level changes. The minor and patch version
numbers MUST be reset to 0 when the major version number is
incremented.
5.20.1.2. The Attribute "supaVersionMinor" 5.20.1.2. The Attribute "supaVersionMinor"
This is an optional string attribute, and contains a string This is a mandatory string attribute, and contains a string
(typically representing an integer) indicating that this release representation of an integer that is greater than or equal to zero.
contains a set of features and/or bug fixes that collectively do It indicates that this release contains a set of features and/or
not warrant incrementing the supaVersionMajor attribute. This bug fixes that MUST be backwards-compatible.
attribute should only be used if the supaVersionMajor attribute
is NOT NULL.
5.20.1.3. The Attribute "supaVersionRelType" 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
incremented if any features are marked as deprecated. It MAY be
incremented if new functionality or improvements are introduced.
It MAY include patch level changes. The patch version number MUST
be reset to 0 when the minor version number is incremented.
This is an optional integer attribute, and contains a string 5.20.1.3. The Attribute "supaVersionPatch"
defining the type of release of this SUPAPolicyObject. Values
include:
0: undefined This is a mandatory string attribute, and contains a string
1: internal representation of an integer that is greater than or equal to zero.
2: alpha It indicates that this version contains ONLY bug fixes.
3: beta
4: release candidate
5: production
6: maintenance
This attribute should only be used if the supaVersionMinor The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented
attribute is NOT NULL. if new, backwards-compatible changes are introduced. A bug fix is
defined as an internal change that fixes incorrect behavior.
5.20.1.4. The Attribute "supaVersionRelTypeNum" 5.20.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 incremental release associated with the defining the pre-release version.
supaVersionRelType class attribute. This attribute should only be
used if the supaVersionRelType attribute is NOT NULL. A pre-release version MAY be denoted by appending a hyphen and a
series of dot-separated identifiers immediately following the patch
version. Identifiers MUST comprise only ASCII alphanumerics and a
hyphen. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT
include leading zeroes. Pre-release versions have a lower
precedence than the associated normal version. A pre-release version
indicates that the version is unstable and might not satisfy the
intended compatibility requirements as denoted by its associated
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.
5.20.1.5. The Attribute "supaVersionBuildMetadata"
This is an optional string attribute, and contains a string defining
the build metadata. Build metadata MAY be denoted by appending a
plus sign and a series of dot-separated identifiers immediately
following the patch or pre-release version. Identifiers MUST be
made up of only ASCII alphanumerics and a hyphen. Identifiers
MUST NOT be empty. Build metadata SHOULD be ignored when determining
version precedence. Examples include: 1.0.0.-alpha+1,
1.0.0+20130313144700, and 1.0.0-beta+exp.sha.5114f85.
6. SUPA ECAPolicyRule Information Model 6. SUPA ECAPolicyRule Information Model
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
skipping to change at page 87, line 45 skipping to change at page 90, line 30
| | | |
| +---SUPABooleanClause (6.7) | +---SUPABooleanClause (6.7)
| | | |
| +---SUPAECAPolicyRuleAtomic (6.8) | +---SUPAECAPolicyRuleAtomic (6.8)
| | | |
| +---SUPAECAPolicyRuleComposite (6.9) | +---SUPAECAPolicyRuleComposite (6.9)
| |
+---SUPAPolicyComponentDecorator (5.9) +---SUPAPolicyComponentDecorator (5.9)
| |
+---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 23. 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
skipping to change at page 92, line 7 skipping to change at page 94, line 45
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).
The composite pattern [3] is applied to the SUPAECAPolicyRule The composite pattern [3] is applied to the SUPAECAPolicyRule
class, enabling its (concrete) subclasses to be used as either a class, enabling its (concrete) subclasses to be used as either a
stand-alone policy rule or as a hierarchy of policy rules. This is stand-alone policy rule or as a hierarchy of policy rules.
SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both
inherit from SUPAECAPolicyRule. This means that they are both
a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule
aggregation enables a particular SUPAECAPolicyRuleComposite
object to aggregate both SUPAECAPolicyRuleComposite as well as
SUPAECAPolicyRuleAtomic objects. In contrast, a
SUPAECAPolicyRuleAtomic can NOT aggregate either a
SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic.
SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are
defined in sections 6.5 and 6.6, respectively. This is
shown in Figure 25. shown in Figure 25.
A A
1..n +-------------------+ 1..n +-------------------+
\| | \| |
+--------------- + SUPAECAPolicyRule | +--------------- + SUPAECAPolicyRule |
| /| | | /| |
| +--------+----------+ | +--------+----------+
| / \ | / \
| SUPAHasECAPolicyRule I | SUPAHasECAPolicyRule I
skipping to change at page 92, line 32 skipping to change at page 95, line 27
| 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 25. The Composite Pattern Applied to a SUPAECAPolicyRule
SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both
inherit from SUPAECAPolicyRule. This means that they are both
a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule
aggregation enables a particular SUPAECAPolicyRuleComposite
object to aggregate both SUPAECAPolicyRuleComposite as well as
SUPAECAPolicyRuleAtomic objects. In contrast, a
SUPAECAPolicyRuleAtomic can NOT aggregate either a
SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic.
SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are
defined in sections 6.5 and 6.6, respectively.
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 95, line 36 skipping to change at page 98, line 20
(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.3. The Association Class "SUPAHasECAPolicyRuleDetail"
This is an optional association class, and defines the semantics This is an optional concrete association class, and defines the
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 SUPHasECAPolicyRule objects
can be aggregated by this particular SUPAECAPolicyRuleComposite can be aggregated by this particular SUPAECAPolicyRuleComposite
object instance. object instance.
6.6.3.1. The Attribute "supaECAPolicyIsDefault" 6.6.3.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
skipping to change at page 98, line 12 skipping to change at page 100, line 49
SUPABooleanClauseComposite objects, including the outermost SUPABooleanClauseComposite objects, including the outermost
SUPABooleanClauseComposite object, are separately manageable. SUPABooleanClauseComposite object, are separately manageable.
More importantly, each SUPAECAPolicyRuleComposite 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 SUPABooleanClauseAtomic 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 Two attributes are currently defined for the
SUPABooleanClauseComposite class, and are described in the SUPABooleanClauseComposite class, and are described in the
following subsections. following subsections.
6.9.1.1. The Attribute "supaBoolClauseBindValue" 6.9.1.1. The Attribute "supaBoolClauseBindValue"
This is a mandatory non-zero integer attribute, and defines the This is a mandatory non-zero integer attribute, and defines the
order in which terms bind to a clause. For example, the Boolean 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 expression "((A AND B) OR (C AND NOT (D OR E)))" has the following
skipping to change at page 99, line 5 skipping to change at page 101, line 41
(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 Concrete Class "SUPAHasBooleanClauseDetail" 6.9.3. The Association Class "SUPAHasBooleanClauseDetail"
This is a mandatory association class that defines the semantics This is a mandatory concrete association class that defines the
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.3.1. SUPAHasBooleanClauseDetail Attributes
The SUPAHasBooleanClauseDetail class currently does not define The SUPAHasBooleanClauseDetail class currently does not define
any attributes at this time. any attributes.
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
skipping to change at page 100, line 23 skipping to change at page 103, line 9
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 any important occurrence in time of a an Event is defined as anything of importance to the management
change in the system being managed, and/or in the environment of system (e.g., a change in the system being managed and/or its
the system being managed. SUPAPolicyEvents can be used as part of environment) occuring on a time-axis (as defined in [19]).
a SUPAPolicyClause; this is done by specifying the attribute name SUPAPolicyEvents can be used as part of a SUPAPolicyClause; this
and value of an Event in the supaPolicyEventData attribute of the is done by specifying the attribute name and value of an Event in
SUPAPolicyEvent. This enables event attributes to be used as part the supaPolicyEventData attribute of the SUPAPolicyEvent. This
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. Note: this class does NOT model the "raw" occurrences of Events.
Rather, it represents the concept of an Event object whose class Rather, it represents the concept of an Event object whose class
attributes describe pertinent attributes that can trigger the attributes describe pertinent attributes that can trigger the
evaluation of a SUPAECAPolicyRule. evaluation of a SUPAECAPolicyRule.
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.
skipping to change at page 101, line 38 skipping to change at page 104, line 23
This is a mandatory attribute that defines an array of strings. This is a mandatory attribute that defines an array of strings.
Each string in the array represents an attribute name and value Each string in the array represents an attribute name and value
of an Event object. The format of each string is defined as of an Event object. The format of each string is defined as
name:value. The 'name' part is the name of the SUPAPolicyEvent name:value. The 'name' part is the name of the SUPAPolicyEvent
attribute, and the 'value' part is the value of that attribute. attribute, and the 'value' part is the value of that attribute.
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. For example, if at least one (and possibly more) attributes. For example, if
this value of this attribute is: this value of this attribute is:
{(startTime:0800), (endTime:1700)} {(startTime:0800), (endTime:1700), (date:2016-05-11),
(timeZone:-08:00)}
then this attribute contains two properties, called startTime and then this attribute contains four properties, called startTime,
endTime, whose values are 0800 and 1700, respectively. endTime, date, and timeZone whose values are 0800, 1700, May 11
2016, and Pacific Standard Time, respectively.
Note that the supaPolicyEventEncoding class attribute defines how Note that the supaPolicyEventEncoding class attribute defines how
to interpret the value portion of this attribute. to interpret the value portion of this attribute.
This attribute works with another class attribute, called This attribute works with another class attribute, called
supaPolicyEventEncoding, which defines how to interpret this supaPolicyEventEncoding, which defines how to interpret this
attribute. These two attributes form a tuple, and together enable attribute. These two attributes form a tuple, and together enable
a machine to understand the syntax and value of the data carried a machine to understand the syntax and value of the data carried
by the object instance of this class. by the object instance of this class.
skipping to change at page 102, line 48 skipping to change at page 105, line 38
to understand the syntax and value of the content of this to understand the syntax and value of the content of this
SUPAPolicyCondition object. Values include: SUPAPolicyCondition object. Values include:
0: undefined 0: undefined
1: String 1: String
2: OCL 2.x 2: OCL 2.x
3: OCL 1.x 3: OCL 1.x
4: QVT 1.2 - Relations Language 4: QVT 1.2 - Relations Language
5: QVT 1.2 - Operational language 5: QVT 1.2 - Operational language
6: Alloy 6: Alloy
7: English text
Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the
latest version as of this writing). QVT defines a set of languages
(the two most powerful and useful are defined by enumerations 4
and 5). Alloy is a language for describing constraints, and uses a
SAT solver to guarantee correctness. Note that enumeration 7
(English text) is not recommended (since it is informal, and hence,
not verifiable), but included for completeness.
6.12.2. SUPAPolicyEvent Relationships 6.12.2. SUPAPolicyEvent Relationships
No relationships are currently defined for this class. It inherits No relationships are currently defined for this class. It inherits
the relationships defined by the SUPAPolicyComponentDecorator (see the relationships defined by the SUPAPolicyComponentDecorator (see
section 5.7.3.). section 5.7.3.).
6.13. The Concrete Class "SUPAPolicyAction" 6.13. The Concrete Class "SUPAPolicyAction"
This is a mandatory concrete class that represents the concept of This is a mandatory concrete class that represents the concept of
skipping to change at page 105, line 7 skipping to change at page 108, line 7
8. Security Considerations 8. Security Considerations
This will be defined in the next version of this document. This will be defined in the next version of this document.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. Contributors 10. Contributors
The following people contributed significantly to the previous The following people contributed to creating this document, and are
versions of this document: listed in alphabetical order:
- Jason Coleman (Cisco) Jason Coleman
11. Acknowledgments 11. Acknowledgments
This document has benefited from reviews, suggestions, comments This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in and proposed text provided by the following members, listed in
alphabetical order: Andy Bierman, Bob Natale, Fred Feisullin, alphabetical order: Andy Bierman, Bert Wijnen, Bob Natale, Dave
Georgios Karagiannis, Liu (Will) Shucheng, Marie-Jose Montpetit. Hood, Fred Feisullin, Georgios Karagiannis, Liu (Will) Shucheng,
Marie-Jose Montpetit.
12. References 12. References
This section defines normative and informative references for this This section defines normative and informative references for this
document. document.
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 107, line 7 skipping to change at page 110, line 11
[13] Liskov, B.H., Wing, J.M., "A Behavioral Notion of [13] Liskov, B.H., Wing, J.M., "A Behavioral Notion of
subtyping", ACM Transactions on Programming languages subtyping", ACM Transactions on Programming languages
and Systems, 16 (6): 1811 - 1841, 1994 and Systems, 16 (6): 1811 - 1841, 1994
[14] Martin, R.C., "Agile Software Development, Principles, [14] Martin, R.C., "Agile Software Development, Principles,
Patterns, and Practices", Prentice-Hall, 2002, Patterns, and Practices", Prentice-Hall, 2002,
ISBN: 0-13-597444-5 ISBN: 0-13-597444-5
[15] Halpern, J., Strassner, J., "Generic Policy Data Model [15] Halpern, J., Strassner, J., "Generic Policy Data Model
for Simplified Use of Policy Abstractions (SUPA)" for Simplified Use of Policy Abstractions (SUPA)"
draft-halpern-supa-generic-policy-data-model-01, draft-ietf-supa-generic-policy-data-model-00,
April 15, 2016 July 13, 2016
[16] Wang, Y., Esposito, F., Matta, I., Day, J., "RINA: An
Architecture for Policy-based Dynamic Service
Management", Tech Report BUCS-TR-2013-014, 2013
[17] Meyer, B., "Object-Oriented Software Construction",
Prentice Hall, second edition, 1997 ISBN 0-13-629155-4
[18] http://semver.org/
[19] ISO/IEC:2004(E), "Data elements and interchange
formats -- Information interchange -- Representation
of dates and times", 2004
Authors' Addresses Authors' Addresses
John Strassner John Strassner
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95138 USA Santa Clara, CA 95138 USA
Email: john.sc.strassner@huawei.com Email: john.sc.strassner@huawei.com
Joel Halpern Joel Halpern
Ericsson Ericsson
P. O. Box 6049 P. O. Box 6049
Leesburg, VA 20178 Leesburg, VA 20178
Email: joel.halpern@ericsson.com Email: joel.halpern@ericsson.com
Sven van der Meer
LM Ericsson Ltd.
Ericsson Software Campus
Garrycastle
Athlone
N37 PV44
Ireland
Email: sven.van.der.meer@ericsson.com
Appendix A. Brief Analyses of Previous Policy Work Appendix A. Brief Analyses of Previous Policy Work
This appendix describes of some of the important problems with This appendix describes of some of the important problems with
previous IETF policy work., and describes the rationale for previous IETF policy work., and describes the rationale for
taking different design decisions in this document. taking different design decisions in this document.
A.1. PolicySetComponent vs. SUPAPolicyStructure A.1. PolicySetComponent vs. SUPAPolicyStructure
The ability to define different types of policy rules is not The ability to define different types of policy rules is not
present in [RFC3060] and [RFC3460], because both are based on [4], present in [RFC3060] and [RFC3460], because both are based on [4],
skipping to change at page 110, line 7 skipping to change at page 113, line 26
second is that PolicyGroups cannot aggregate PolicyRules (which second is that PolicyGroups cannot aggregate PolicyRules (which
again implies that PolicyGroups are not needed). again implies that PolicyGroups are not needed).
Furthermore, there are no mechanisms defined in the [RFC3460] Furthermore, there are no mechanisms defined in the [RFC3460]
model to prevent loops of PolicyRules. This is a problem, because model to prevent loops of PolicyRules. This is a problem, because
EVERY PolicyRule and PolicyGroup inherits this recursive EVERY PolicyRule and PolicyGroup inherits this recursive
aggregation. aggregation.
This is why this document uses the composite pattern. First, this This is why this document uses the composite pattern. First, this
pattern clearly shows what object is aggregating what other pattern clearly shows what object is aggregating what other
object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate ability object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate a
SUPAECAPolicyRuleComposite). Second, it does not allow ability SUPAECAPolicyRuleComposite). Second, it does not allow a
SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule
(this is discussed more in the following subsection). (this is discussed more in the following subsection).
A.3.1. Sub-rules A.3.1. Sub-rules
Sub-rules (also called nested policy rules) enable a policy rule to Sub-rules (also called nested policy rules) enable a policy rule to
be contained within another policy rule. These have very complex be contained within another policy rule. These have very complex
semantics, are very hard to debug, and provide limited value. They semantics, are very hard to debug, and provide limited value. They
also require a complex set of aggregations (see section A.4.). also require a complex set of aggregations (see section A.4.).
skipping to change at page 113, line 33 skipping to change at page 118, line 7
[RFC3460] defined a set of 7 subclasses; three were specific to [RFC3460] defined a set of 7 subclasses; three were specific to
networking (i.e., IPv4 Address, IPv6 Address, MAC Address) and 4 networking (i.e., IPv4 Address, IPv6 Address, MAC Address) and 4
(PolicyStringValue, PolicyBitStringValue, PolicyIntegerValue, and (PolicyStringValue, PolicyBitStringValue, PolicyIntegerValue, and
PolicyBooleanValue) were generic in nature. However, each of these PolicyBooleanValue) were generic in nature. However, each of these
objects defined a single class attribute. This has the same two objects defined a single class attribute. This has the same two
problems as with PolicyVariables (see section 5.9.1.1): problems as with PolicyVariables (see section 5.9.1.1):
1. Using an entire object to define a single attribute is very 1. Using an entire object to define a single attribute is very
wasteful and expensive wasteful and expensive
2. It also make it difficult to adjust constraints at runtime, 2. It also make it difficult to adjust constraints at runtime,
since the constraint is defined in a class that is statically since the constraint is defined in a class that is statically
defined (and hence, requires recompilation and possibly defined (and hence, requires recompilation and possibly
redeployment if it is changed). redeployment if it is changed).
A.8.2. Object Explosion A.8.2. Object Explosion
[RFC3460] definition requires the use of associations [RFC3460] definition requires the use of associations
in order to properly constrain the variable (e.g., define its in order to properly constrain the variable (e.g., define its
data type, the range of its allowed values, etc.). This is both data type, the range of its allowed values, etc.). This is both
costly and inefficient (recall that in [RFC3060], [RFC3460], and costly and inefficient (recall that in [RFC3060], [RFC3460], and
skipping to change at page 114, line 31 skipping to change at line 5765
[RFC3460] has no symmetry in how it defines variables and values. [RFC3460] has no symmetry in how it defines variables and values.
In contrast, this document recognizes that variables and values In contrast, this document recognizes that variables and values
are just terms in a clause; hence, the only difference in the are just terms in a clause; hence, the only difference in the
definition of the SUPAPolicyVariable and SUPAPolicyValue classes definition of the SUPAPolicyVariable and SUPAPolicyValue classes
is that the content attribute in the former is a single string, is that the content attribute in the former is a single string,
whereas the content attribute in the latter is a string array. whereas the content attribute in the latter is a string array.
In particular, the semantics of both variables and values are In particular, the semantics of both variables and values are
defined using the decorator pattern, along with the attributes of defined using the decorator pattern, along with the attributes of
the SUPAPolicyComponentDecorator and the the SUPAPolicyComponentDecorator and the
SUPAHasDecoratedPolicyComponentDetail classes. SUPAHasDecoratedPolicyComponentDetail classes.
Appendix B. Mathematical Logic Terminology and Symbology
Appendix C. SUPA Logic Statement Information Model
 End of changes. 188 change blocks. 
519 lines changed or deleted 685 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/