Network Working Group                                     J. Strassner
Internet Draft                                     Huawei Technologies
Intended status: Standard Track                             J. Halpern
Expires: July 20, November 30, 2017                             S. van der Meer
                                                              Ericsson
                                                      January 18,
                                                          May 30, 2017

                  Generic Policy Information Model for
              Simplified Use of Policy Abstractions (SUPA)
           draft-ietf-supa-generic-policy-info-model-02
              draft-ietf-supa-generic-policy-info-model-03

Abstract

   This document defines an information model for representing
   policies using a common extensible framework that is independent
   of language, protocol, repository. It is also independent of the
   level of abstraction of the content and meaning of a policy.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current
   Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   This Internet-Draft will expire on July 20, November 30, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided
   without warranty as described in the Simplified BSD License.

Table of Contents
*** Note: this is out of date, will be fixed in next version ***

1.  Overview ....................................................... 9
   1.1.  Introduction .............................................. 9
   1.2.  Changes Since Version -03 ................................ 11
2.  Conventions Used in This Document ............................. 11
3.  Terminology ................................................... 12
   3.1.  Acronyms ................................................. 12
   3.2.  Definitions .............................................. 12
      3.2.1.  Core Terminology .................................... 12
         3.2.1.1.  Information Model .............................. 12
         3.2.1.2.  Data Model ..................................... 13
         3.2.1.3.  Class .......................................... 13
         3.2.1.3.1.  Abstract Class ............................... 13
         3.2.1.3.2.  Concrete Class ............................... 13
         3.2.1.4.  Container ...................................... 13
         3.2.1.5.  PolicyContainer ................................ 13
      3.2.2.  Policy Terminology .................................. 14
         3.2.2.1.  SUPAPolicyObject ............................... 14
         3.2.2.2.  SUPAPolicy ..................................... 14
         3.2.2.3.  SUPAPolicyClause ............................... 14
         3.2.2.4.  SUPAECAPolicyRule .............................. 15
         3.2.2.5.  SUPAMetadata ................................... 15
         3.2.2.6.  SUPAPolicyTarget ............................... 15
         3.2.2.7.  SUPAPolicySource ............................... 15
      3.2.3.  Modeling Terminology ................................ 16
         3.2.3.1.  Inheritance .................................... 16
         3.2.3.2.  Relationship ................................... 16
         3.2.3.3.  Association .................................... 17
         3.2.3.4.  Aggregation .................................... 17
         3.2.3.5.  Composition .................................... 17
         3.2.3.6.  Association Class .............................. 17
         3.2.3.7.  Multiplicity ................................... 18
         3.2.3.8.  Navigability ................................... 18
   3.3.  Symbology ................................................ 18
      3.3.1.  Inheritance ......................................... 18
      3.3.2.  Association ......................................... 19
      3.3.3.  Aggregation ......................................... 19
      3.3.4.  Composition ......................................... 19
      3.3.5.  Association Class ................................... 19
      3.3.6.  Abstract vs. Concrete Classes ....................... 20
4.  Policy Abstraction Architecture ............................... 21
   4.1.  Motivation ............................................... 22
   4.2.  SUPA Approach ............................................ 23
      4.2.1.  Design Patterns ..................................... 23
         4.2.1.1.  Composite Pattern .............................. 24
         4.2.1.2.  Decorator Pattern .............................. 24
      4.2.2.  Association Classes ................................. 26

Table of Contents (continued)

   4.3.  SUPA Generic Policy Information Model Overview............ 23 27
      4.3.1.  SUPAPolicyObject .................................... 25 29
      4.3.2.  SUPAPolicyStructure ................................. 26 30
      4.3.3.  SUPAPolicyComponentStructure ........................ 26 30
      4.3.4.  SUPAPolicyClause .................................... 27 31
      4.3.5.  SUPAPolicyComponentDecorator ........................ 27  SUPAPolicyClauseComponentDecorator .................. 31
      4.3.6.  SUPAPolicyTarget .................................... 28 32
      4.3.7.  SUPAPolicySource .................................... 28 32
   4.4.  The Design of the GPIM ................................... 28 32
      4.4.1.  Structure of Policies ............................... 29 33
      4.4.2.  Representing an ECA Policy Rule ..................... 30 34
      4.4.3.  Creating SUPA Policy Clauses ........................ 33 37
      4.4.4.  Creating SUPAPolicyClauses .......................... 36 41
      4.4.5.  SUPAPolicySources ................................... 37 42
      4.4.6.  SUPAPolicyTargets ................................... 39 43
      4.4.7.  SUPAPolicyMetadata .................................. 39 43
         4.4.7.1.  Motivation ..................................... 39 44
         4.4.7.2.  Design Approach ................................ 40 45
            4.4.7.2.1.  Policies and Actors ....................... 42 46
            4.4.7.2.2.  Deployment vs. Execution of Policies ...... 43 47
            4.4.7.2.3.  Using SUPAMetadata for Policy Deployment
                        and Execution ............................. 43 47
         4.4.7.3.  Structure of SUPAPolicyMetadata ................ 44
   4.5.  Advanced Features ........................................ 47
      4.5.1.  Policy Grouping ..................................... 47
      4.5.2.  Policy Rule Nesting ................................. 47 48
5.  GPIM Model .................................................... 48 52
   5.1.  Overview ................................................. 48 52
   5.2.  The Abstract Class "SUPAPolicyObject" .................... 49 53
      5.2.1.  SUPAPolicyObject Attributes ......................... 50 54
         5.2.1.1.  Object Identifiers ............................. 50 54
         5.2.1.2.  The Attribute "supaPolObjIDContent" ............ 51 55
         5.2.1.3.  The Attribute "supaPolObjIDEncoding" ........... 51 55
         5.2.1.4.  The Attribute "supaPolicyDescription" .......... 51 55
         5.2.1.5.  The Attribute "supaPolicyName" ................. 51 55
      5.2.2.  SUPAPolicy Relationships ............................ 52 56
         5.2.2.1.  The Relationship "SUPAHasPolicyMetadata" ....... 52 56
         5.2.2.2.  The Association Class
                   "SUPAHasPolicyMetadataDetail" .................. 52 56
   5.3.  The Abstract Class "SUPAPolicyStructure" ................. 52 56
      5.3.1.  SUPAPolicyStructure Attributes ...................... 53 57
         5.3.1.1.  The Attribute "supaPolAdminStatus" ............. 53 57
         5.3.1.2.  The Attribute "supaPolContinuumLevel" .......... 53 57
         5.3.1.3.  The Attribute "supaPolDeployStatus" ............ 54 58
         5.3.1.4.  The Attribute "supaPolExecFailStrategy" ........ 54

Table of Contents (continued) 58
      5.3.2.  SUPAPolicyStructure Relationships ................... 55 59
         5.3.2.1.  The Aggregation "SUPAHasPolicySource" .......... 55 59
         5.3.2.2.  The Association Class
                   "SUPAHasPolicySourceDetail" .................... 55 59
            5.3.2.2.1.  The Attribute "supaPolSrcIsAuthenticated" . 55 59
            5.3.2.2.2.  The Attribute "supaPolSrcIsTrusted" ....... 56 59

Table of Contents (continued)

         5.3.2.3.  The Aggregation "SUPAHasPolicyTarget" .......... 56 59
         5.3.2.4.  The Association Class
                   "SUPAHasPolicyTargetDetail"  ................... 56 60
            5.3.2.4.1.  The Attribute "supaPolTgtIsAuthenticated" . 56 60
            5.3.2.4.2.  The Attribute "supaPolTgtIsEnabled" ....... 56 60
         5.3.2.5.  The Association "SUPAHasPolExecFailTakeAction" . 57 60
         5.3.2.6.  The Association Class
                   "SUPAHasPolExecFailTakeActionDetail" ........... 57 61
            5.3.2.6.1.  The Attribute
                        "supaPolExecFailActionEncoding" ........... 57 61
            5.3.2.6.2.  The Attribute
                        "supaPolExecFailActionName[1..n]" ......... 58 62
         5.3.2.7.  The Aggregation "SUPAHasPolicyClause" .......... 58 62
         5.3.2.8.  The Association Class
                   "SUPAHasPolicyClauseDetail" .................... 58 63
   5.4.  The Abstract Class "SUPAPolicyComponentStructure" ........ 59 63
      5.4.1.  SUPAPolicyComponentStructure Attributes ............. 59 63
      5.4.2.  SUPAPolicyComponentStructure Relationships .......... 59 63
   5.5.  The Abstract Class "SUPAPolicyClause" .................... 59 64
      5.5.1.  SUPAPolicyClause Attributes ......................... 60 65
         5.5.1.1.  The Attribute "supaPolClauseDeployStatus" ...... 60 65
      5.5.2.  SUPAPolicyClause Relationships ...................... 61 65
         5.5.2.1.  The Aggregation "SUPAPolicyClauseHasDecorator" . 66
         5.5.2.2.  The Association Class
                   "SUPAPolicyClauseHasDecoratorDetail" ........... 66
            5.5.2.2.1.  The Attribute
                        "supaPolClauseDecConstraintEncoding" ...... 66
            5.5.2.2.2.  The Attribute
                        "supaPolClauseDecConstraint[0..n]" ........ 66
   5.6.  The Concrete Class "SUPAEncodedClause" ................... 61 67
      5.6.1.  SUPAEncodedClause Attributes ........................ 61 67
         5.6.1.1.  The Attribute "supaEncodedClauseContent" ....... 61 68
         5.6.1.2.  The Attribute "supaEncodedClauseEncoding" ...... 61 68
         5.6.1.3.  The Attribute "supaEncodedClauseLanguage" ...... 62 68
         5.6.1.4.  The Attribute "supaEncodedClauseResponse" ...... 62 69
      5.6.2.  SUPAEncodedClause Relationships ..................... 62 69
   5.7.  The Abstract Class "SUPAPolicyComponentDecorator" ........ 62 "SUPAPolicyClauseComponentDecorator ... 69
      5.7.1.  The Decorator Pattern ............................... 63
      5.7.2.  SUPAPolicyComponentDecorator  SUPAPolicyClauseComponentDecorator Attributes ............. 64
         5.7.2.1. ....... 70
         5.7.1.1.  The Attribute "supaPolCompConstraintEncoding" .. 65
         5.7.2.2. "supaPolClauseConstraintEncoding"  70
         5.7.1.2.  The Attribute "supaAPolCompConstraint[0..n]" ... 65
      5.7.3.  SUPAPolicyComponentDecorator "supaPolClauseConstraint[0..n]" .. 71
      5.7.2.  SUPAPolicyClauseComponentDecorator Relationships .......... 65
         5.7.3.1.  The Aggregation
                   "SUPAHasDecoratedPolicyComponent" .............. 66
         5.7.3.2.  The Association Class
                   "SUPAHasDecoratedPolicyComponentDetail" ........ 66
            5.7.3.2.1.  The Attribute
                        "supaDecoratedConstraintEncoding" ......... 66
            5.7.3.2.2.  The Attribute
                        "supaDecoratedConstraint[0..n]" ........... 67

Table of Contents (continued)

      5.7.4. .... 71
      5.7.3.  Illustration of Constraints in the Decorator Pattern  67  71
   5.8.  The Abstract Class "SUPAPolicyTerm" ...................... 68 72
      5.8.1.  SUPAPolicyTerm Attributes ........................... 69 73
         5.8.1.1.  The Attribute "supaPolTermIsNegated" ........... 69 73
      5.8.2.  SUPAPolicyTerm Relationships ........................ 69 73

Table of Contents (continued)

   5.9.  The Concrete Class "SUPAPolicyVariable" .................. 69 74
      5.9.1.  Problems with the RFC3460 Version of PolicyVariable . 70 74
      5.9.2.  SUPAPolicyVariable Attributes ....................... 70 74
         5.9.2.1.  The Attribute "supaPolVarName" ................. 70 74
      5.9.3.  SUPAPolicyVariable Relationships .................... 70 75
   5.10.  The Concrete Class "SUPAPolicyOperator" ................. 70 75
      5.10.1.  Problems with the RFC3460 Version .................. 71 75
      5.10.2.  SUPAPolicyOperator Attributes ...................... 71 75
         5.10.2.1.  The Attribute "supaPolOpType" ................. 71 75
      5.10.3.  SUPAPolicyOperator Relationships ................... 71 76
   5.11.  The Concrete Class "SUPAPolicyValue" .................... 72 76
      5.11.1.  Problems with the RFC3460 Version of PolicyValue ... 72 77
      5.11.2.  SUPAPolicyValue Attributes ......................... 72 77
         5.11.2.1.  The Attribute "supaPolValContent[0..n]" ....... 72 77
         5.11.2.2.  The Attribute "supaPolValEncoding" ............ 73 77
      5.11.3.  SUPAPolicyValue Relationships ...................... 73 78
   5.12.  The Concrete Class "SUPAGenericDecoratedComponent" ...... 73 78
      5.12.1.  SUPAGenericDecoratedComponent Attributes ........... 74 78
         5.12.1.1.  The Attribute
                    "supaVendorDecoratedCompContent[0..n]" ........ 74
                    "supaGenericDecoratedCompContent[0..n]" ....... 79
         5.12.1.2.  The Attribute "supaVendorDecoratedCompEncoding" 74
                    "supaGenericDecoratedCompEncoding" ............ 79
      5.12.2.  SUPAGenericDecoratedComponent Relationships ........ 74 79
   5.13.  The Concrete Class "SUPAPolicyCollection" ............... 75 80
      5.13.1.  Motivation ......................................... 75 80
      5.13.2.  Solution ........................................... 75 80
      5.13.3.  SUPAPolicyCollection Attributes .................... 76 81
         5.13.3.1.  The Attribute "supaPolCollectionContent[0..n]"  76  81
         5.13.3.2.  The Attribute "supaPolCollectionEncoding" ..... 76 81
         5.13.3.3.  The Attribute "supaPolCollectionFunction" ..... 76 81
         5.13.3.4.  The Attribute "supaPolCollectionIsOrdered" .... 76 82
         5.13.3.5.  The Attribute "supaPolCollectionType" ......... 77 82
      5.13.4.  SUPAPolicyCollection Relationships ................. 78 83
   5.14.  The Abstract Class "SUPAPolicyComponentDecorator ........ 83
      5.14.1.  SUPAPolicyComponentDecorator Attributes ............ 84
         5.14.1.1.  The Attribute "supaPolCompConstraintEncoding" . 84
         5.14.1.2.  The Attribute "supaPolCompConstraint[0..n]" ... 85
      5.14.2.  SUPAPolicyComponentDecorator Relationships ......... 85
         5.14.2.1.  The Aggregation
                    "SUPAHasDecoratedPolicyComponent" ............. 85
         5.14.2.2.  The Association Class
                    "SUPAHasDecoratedPolicyComponentDetail" ....... 85
            5.14.2.1.1.  The Attribute
                         "supaPolCompConstraintEncoding" .......... 86
            5.14.2.1.2.  The Attribute
                         "supaPolCompConstraint[0..n]" ............ 86

Table of Contents (continued)

  5.15.  The Concrete Class "SUPAPolicySource" .................... 78
      5.14.1. 86
      5.15.1.  SUPAPolicySource Attributes ........................ 78
      5.14.2. 86
      5.15.2.  SUPAPolicySource Relationships ..................... 78
   5.15. 87
   5.16.  The Concrete Class "SUPAPolicyTarget" ................... 78
      5.15.1. 87
      5.16.1.  SUPAPolicyTarget Attributes ........................ 79
      5.15.2. 87
      5.16.2.  SUPAPolicyTarget Relationships ..................... 79

Table of Contents (continued)

   5.16. 87
   5.17.  The Abstract Class "SUPAPolicyMetadata" ................. 79
      5.16.1. 88
      5.17.1.  SUPAPolicyMetadata Attributes ...................... 80
         5.16.1.1. 89
         5.17.1.1.  The Attribute "supaPolMetadataDescription" .... 80
         5.16.1.2. 89
         5.17.1.2.  The Attribute "supaPolMetadataIDContent" ...... 80
         5.16.1.3. 89
         5.17.1.3.  The Attribute "supaPolMetadataIDEncoding" ..... 80
         5.16.1.4. 89
         5.17.1.4.  The Attribute "supaPolMetadataName" ........... 81
      5.16.2. 90
      5.17.2.  SUPAPolicyMetadata Relationships ................... 81
         5.16.2.1. 90
         5.17.2.1.  The Aggregation "SUPAHasPolicyMetadata" ....... 81
         5.16.2.2. 90
         5.17.2.2.  The Association Class
                    "SUPAHasPolicyMetadataDetail" ................. 81
            5.16.2.2.1.  The Attribute
                         "supaPolMetadataIsApplicable" ............ 81
            5.16.2.2.2. 90
            5.17.2.2.1.  The Attribute
                         "supaPolMetadataConstraintEncoding" ...... 82
            5.16.2.2.3. 90
            5.17.2.2.2.  The Attribute
                         "supaPolMetadataConstraint[0..n]" ........ 82
   5.17. 91
            5.17.2.2.3.  The Attribute
                         "supaPolMetadataIsApplicable" ............ 91
   5.18.  The Concrete Class "SUPAPolicyConcreteMetadata" ......... 82
      5.17.1. 91
      5.18.1.  SUPAPolicyConcreteMetadata Attributes .............. 83
          5.17.1.1. 91
          5.18.1.1.  The Attribute "supaPolMDValidPeriodEnd" ...... 83
          5.17.1.2. 92
          5.18.1.2.  The Attribute "supaPolMDValidPeriodStart" .... 83
      5.17.2. 92
      5.18.2.  SUPAPolicyConcreteMetadata Relationships ........... 83
   5.18. 92
   5.19.  The Abstract Class "SUPAPolicyMetadataDecorator" ........ 83
      5.18.1. 92
      5.19.1.  SUPAPolicyMetadataDecorator Attributes ............. 83
      5.18.2. 92
      5.19.2.  SUPAPolicyMetadataDecorator Relationships .......... 83
         5.18.2.1. 92
         5.19.2.1.  The Aggregation "SUPAHasMetadataDecorator" .... 84
         5.18.2.2. 92
         5.19.2.2.  The Association Class
                    "SUPAHasMetadataDecoratorDetail" .............. 84
   5.19. 93
            5.19.2.2.1.  The Attribute
                         "supaPolMetadataConstraintEncoding" ...... 93
            5.19.2.2.2.  The Attribute
                         "supaPolMetadataConstraint[0..n]" ........ 94
            5.19.2.2.3.  The Attribute
                         "supaPolMetadataDecIsApplicable" ......... 94
   5.20.  The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 84
      5.19.1. 94
      5.20.1.  SUPAPolicyAccessMetadataDef Attributes ............. 85
         5.19.1.1. 94
         5.20.1.1.  The Attribute "supaAccessPrivilegeDef" ........ 85
         5.19.1.2. "supaPolAccessPrivilegeDef" ..... 94
         5.20.1.2.  The Attribute "supaAccessPrivilegeModelName" .. 85
         5.19.1.3. "supaPolAccessPrivilegeModelName" 95
         5.20.1.3.  The Attribute "supaAccessPrivilegeModelRef" ... 86
   5.20. "supaPolAccessPrivilegeModelRef"  95

Table of Contents (continued)

   5.21.  The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 86
      5.20.1. 96
      5.21.1.  SUPAPolicyVersionMetadataDef Attributes ............ 86
         5.20.1.1. 96
         5.21.1.1.  The Attribute "supaVersionMajor" .............. 87
         5.20.1.2. 97
         5.21.1.2.  The Attribute "supaVersionMinor" .............. 88
         5.20.1.3. 98
         5.21.1.3.  The Attribute "supaVersionPatch" .............. 88
         5.20.1.4. 98
         5.21.1.4.  The Attribute "supaVersionPreRelease" ......... 88
         5.20.1.5. 98
         5.21.1.5.  The Attribute "supaVersionBuildMetadata" ...... 89 98
6.  SUPA ECAPolicyRule Information Model .......................... 89 99
   6.1.  Overview ................................................. 89 99
   6.2.  Constructing a SUPAECAPolicyRule ......................... 91 ........................ 101
   6.3.  Working With SUPAECAPolicyRules .......................... 92 ......................... 101
   6.4.  The Abstract Class "SUPAECAPolicyRule" ................... 93 .................. 103
      6.4.1.  SUPAECAPolicyRule Attributes ........................ 95 ....................... 105
         6.4.1.1.  The Attribute "supaECAPolicyRulePriority" ...... 95 ..... 105
         6.4.1.2.  The Attribute "supaECAPolicyRuleStatus" ........ 95 ....... 105
      6.4.2.  SUPAECAPolicyRule Relationships ..................... 96

Table of Contents (continued) .................... 105
   6.5.  The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 96 ............ 105
      6.5.1.  SUPAECAPolicyRuleAtomic Attributes .................. 96 ................. 106
         6.5.1.1.  The Attribute "supaECAPolActionEvalStrategy" .. 106
      6.5.2.  SUPAECAPolicyRuleAtomic Relationships ............... 96 .............. 107
   6.6.  The Concrete Class "SUPAECAPolicyRuleComposite" .......... 96 ......... 107
      6.6.1.  SUPAECAPolicyRuleComposite Attributes ............... 96 .............. 108
         6.6.1.1.  The Attribute "supaECAEvalStrategy" ............ 97 "supaECAEvalRuleStrategy" ....... 108
      6.6.2.  SUPAECAPolicyRuleComposite Relationships ............ 97 ........... 110
         6.6.2.1.  The Aggregation "SUPAHasECAPolicyRule" ......... 98
      6.6.3. ........ 110
         6.6.2.2.  The Association Class
                   "SUPAHasECAPolicyRuleDetail" .. 98
         6.6.3.1. .................. 109
            6.6.2.2.1.  The Attribute "supaECAPolicyIsDefault" ......... 98 ... 109
   6.7.  The Abstract Class "SUPABooleanClause" ................... 98 .................. 109
      6.7.1.  SUPABooleanClause Attributes ........................ 99 ....................... 110
         6.7.1.1.  The Attribute "supaBoolClauseBindValue" ....... 110
         6.7.1.2.  The Attribute "supaBoolClauseIsCNF" ........... 110
         6.7.1.3.  The Attribute "supaBoolClauseIsNegated" ........ 99 ....... 111
      6.7.2.  SUPABooleanClause Relationships ..................... 99 .................... 111
   6.8.  The Concrete Class "SUPABooleanClauseAtomic" ............ 100 111
      6.8.1.  SUPABooleanClauseAtomic Attributes ................. 100 111
      6.8.2.  SUPABooleanClauseAtomic Relationships .............. 100 111
   6.9.  The Concrete Class "SUPABooleanClauseComposite" ......... 100 111
      6.9.1.  SUPABooleanClauseComposite Attributes .............. 100
         6.9.1.1.  The Attribute "supaBoolClauseBindValue" ....... 101
         6.9.1.2.  The Attribute "supaBoolClauseIsCNF" ........... 101 112
      6.9.2.  SUPABooleanClauseComposite Relationships ........... 101 112
         6.9.2.1.  The Aggregation "SUPAHasBooleanClause" ........ 101
      6.9.3. 112
         6.9.2.2.  The Association Class
                   "SUPAHasBooleanClauseDetail" . 101
         6.9.3.1.  SUPAHasBooleanClauseDetail Attributes ......... 101 .................. 112
         6.9.2.2.1.  The Attribute "supaIsHornClause" ............ 112
   6.10.  The Abstract Class "SUPAECAComponent" .................. 102 113
      6.10.1.  SUPAECAComponent Attributes ....................... 102 113
         6.10.1.1.  The Attribute supaECACompIsTerm .............. 102 "supaECACompIsTerm" ............ 113
      6.10.2.  SUPAECAComponent Relationships .................... 102 113

Table of Contents (continued)

   6.11.  The Concrete Class "SUPAPolicyEvent" ................... 103 114
      6.11.1.  SUPAPolicyEvent Attributes ........................ 103 114
         6.11.1.1.  The Attribute "supaPolicyEventIsPreProcessed"  103 "supaPolicyEventData[1..n]" .... 114
         6.11.1.2.  The Attribute "supaPolicyEventIsSynthetic" ... 103 "supaPolicyEventEncoding[1..n]"  115
         6.11.1.3.  The Attribute "supaPolicyEventTopic[0..n]" ... 103 "supaPolicyEventIsPreProcessed"  115
         6.11.1.4.  The Attribute "supaPolicyEventEncoding[1..n]"  103 "supaPolicyEventIsSynthetic" ... 115
         6.11.1.5.  The Attribute "supaPolicyEventData[1..n]" .... 104 "supaPolicyEventTopic[0..n]" ... 116
      6.11.2.  SUPAPolicyEvent Relationships ..................... 104 116
   6.12.  The Concrete Class "SUPAPolicyCondition" ............... 104 116
      6.12.1.  SUPAPolicyCondition Attributes .................... 105 116
         6.12.1.1.  The Attribute "supaPolicyConditionData[1..n]"  105  116
         6.12.1.2.  The Attribute "supaPolicyConditionEncoding" .. 105 117
      6.12.2.  SUPAPolicyEvent  SUPAPolicyCondition Relationships ..................... 105 ................. 117
   6.13.  The Concrete Class "SUPAPolicyAction" .................. 106 117
      6.13.1.  Restrictions about SUPAPolicyActions Calling
               SUPAPolicies ...................................... 118
      6.13.2.  SUPAPolicyAction Attributes ....................... 106
         6.13.1.1. 119
         6.13.2.1.  The Attribute "supaPolicyActionData[1..n]" ... 106
         6.13.1.2. 119
         6.13.2.2.  The Attribute "supaPolicyActionEncoding" ..... 107
      6.13.2. 119
      6.13.3.  SUPAPolicyAction Relationships .................... 107 120
7.  Examples ..................................................... 107 121
   7.1.  Example 1:  Blocking SNMP Traffic ....................... 121
      7.1.1.  Introduction ....................................... 121
      7.1.2.  Solution Approach .................................. 121
         7.1.3.  Solution for Case 1 (SUPAPolicies Control
                 Behavior) ....................................... 122
            7.1.3.1.  Strategy ................................... 123
            7.1.3.2.  Implementation ............................. 124
      7.1.4.  Solution for Case 2 (SUPAPolicies Do Not
              Control Behavior) .................................. 127
         7.1.4.1.  Approach ...................................... 127
            7.1.4.2.  Implementation ............................. 128
8.  Security Considerations  ..................................... 107 130
9.  IANA Considerations .......................................... 107 130
10.  Contributors ................................................ 108 130
11.  Acknowledgments ............................................. 108 130
12.  References .................................................. 108 130
   12.1.  Normative References ................................... 108 130
   12.2.  Informative References  ................................ 108 131
Authors' Addresses ............................................... 109 133
Appendix A.  Brief Analyses of Previous Policy Work .............. 110 134
1.  Overview

   This document defines an information model for representing
   policies using a common extensible framework that is independent
   of language, protocol, repository, and the level of abstraction of
   the content and meaning of a policy. This enables a common set of
   concepts defined in this information model to be mapped into
   different representations of policy (e.g., procedural, imperative,
   and declarative). It also enables different data models that use
   different languages, protocols, and repositories to optimize
   their usage. The definition of common policy concepts also
   provides better interoperability by ensuring that each data
   model can share a set of common concepts, independent of its
   level of detail or the language, protocol, and/or repository
   that it is using. It is also independent of the target data
   model that will be generated.

   This version of the information model focuses on defining one
   type of policy rule: the event-condition-action (ECA) policy rule.
   Accordingly, this document defines two sets of model elements:

      1.  A framework for defining the concept of policy,
          independent of how policy is represented or used; this is
          called the SUPA Generic Policy Information Model (GPIM)
      2.  A framework for defining a policy model that uses the
          event-condition-action (ECA) paradigm; this is called the
          SUPA ECA Policy Rule Information Model (EPRIM), and extends
          concepts from the GPIM.

   The combination of the GPIM and the EPRIM provides an extensible
   framework for defining policy that uses an event-condition-action
   representation that is independent of data repository, data
   definition language, query language, implementation language, and
   protocol.

   The Appendices describe how the structure of the GPIM defines Appendix provides a
   set brief analysis of generic concepts that enables other types previous work in the
   field of policies, such
   as declarative (or "intent-based") policies, to be added later. policy modeling.

1.1.  Introduction

   Simplified Use of Policy Abstractions (SUPA) defines a technology-
   independent neutral information model for creating high-level,
   possibly network-wide policies as input and producing element
   configurations (either whole or snippets) as output. SUPA addresses
   the needs of operators, end-users, and application developers to
   represent multiple types of ECA policy rules, such as for traffic
   selection and configuration or security. These ECA policy rules may
   vary in the level of abstraction to suit the needs of different
   actors (e.g., end-users vs. administrators) [1], [10].

   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.

                        +-------------------+
                        | Information Model |
                        |  and one or more  +<------------------------+
                        |    Data Models    |                         |
                        +-------------------+                         |
                                                                      |
                       +---------------------+                        |
  +---------------+   \| 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

   More importantly, an information model defines concepts in a
   uniform way, enabling formal mapping processes to be developed to
   translate the information model to a set of data models. This
   simplifies the process of constructing software to automate the
   policy management process. It also simplifies the language
   generation process, though that is beyond the scope of this
   document.

   This common framework takes the form of an information model that
   is divided into one high-level module and one or more number of
   lower-level modules. A lower-level module extends the higher-level
   module into a new domain; each lower-level domain module can itself
   be extended to model more granular domain-specific (but still
   technology- and vendor-independent) concepts as necessary.

   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
   (ECA) paradigm.

1.2.  Changes Since Version -01 -02

   There are several changes in this version of this document
   compared to the previous versions of this document. They are:

      1) Clarified figure 7 and figure 17 Fixed ASCII art in several figures
      2) Aligned Added enumerations in IM to supaPolOpType to sync with those in DM and standardized
         values in the IM version and their explanations I2NSF
      3) Removed supaPolExecStatus and supaPolClauseExecStatus Fixed supaVendorDecoratedCompEncoding
      4) Added supaPolClauseDeployStatus Corrected attribute definitions in supaPolicyCollection
      5) Rewrote SUPAPolicyComponentStructure Corrected attribute definition of supaPolMetadataIDEncoding
      6) Rewrote SUPAPolicyClause definition
      7) Synchronized information Added Figures 2 and data models. 3; renumbered subsequent Figures
      7) Enhanced supaPolicyEventEncoding definition
      8) Deleted the attribute "supaEncodedClauseLang[0..n]" Added supaECAPolActionEcalStrategy to SUPAPolicyRuleComposite
      9) Added section 6.13.1.
     10) Added new section about design patterns (4.2.1)
     11) Added new section describing how association classes are
         used (4.2.2)
     12) ECA stuff
     13) revised decorator pattern
     14) Fixed typos

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119]. In
   this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.

3.  Terminology

   This section defines acronyms, terms, and symbology used in the
   rest of this document.

3.1.  Acronyms

   CLI        Command Line Interface
   CRUD       Create, Read, Update, Delete
   CNF        Conjunctive Normal Form
   DNF        Disjunctive Normal Form
   ECA        Event-Condition-Action
   EPRIM      (SUPA) ECA Policy Rule Information Model
   GPIM       (SUPA) Generic Policy Information Model
   OAM&P      Operations, Administration, Management, and Provisioning
   OID        Object IDentifier
   SAT        Satisfiability, short for Boolean Satisfiability Problem
   SUPA       Simplified Use of Policy Abstractions
   TMF        TeleManagent Forum (TM Forum)
   UML        Unified Modeling Language
   URI        Uniform Resource Identifier
   YANG       A data definition language for use with NETCONF
   ZOOM       Zero-touch Orchestration, Operations, and Management
              (a TMF project that also works on information models)

3.2.  Definitions

   This section defines the terminology that is used in this document.

3.2.1.  Core Terminology

   The following subsections define the terms "information model" and
   "data model", as well as "container" and "policy container".

3.2.1.1.  Information Model

   An information model is a representation of concepts of interest
   to an environment in a form that is independent of data repository,
   data definition language, query language, implementation language,
   and protocol.

   Note: this definition is more specific than that of [RFC3198], so
   as to focus on the properties of information models. That definition
   was: "An abstraction and representation of the entities in a managed
   environment, their properties, attributes and operations, and the
   way that they relate to each other. It is independent of any
   specific repository, software usage, protocol, or platform."

3.2.1.2.  Data Model

   A data model is a representation of concepts of interest to an
   environment in a form that is dependent on data repository, data
   definition language, query language, implementation language, and/or
   protocol (typically, but not necessarily, all five).

   Note: this definition is more specific than that of [RFC3198], so
   as to focus on the properties of data models that are generated
   from information models. That definition was: "A mapping of the
   contents of an information model into a form that is specific to a
   particular type of data store or repository."

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.
   It MAY have abstract or concrete subclasses. It is denoted with a
   capital A (for abstract) near the top-left side of the class.

3.2.1.3.2.  Concrete Class

   A concrete class is a class that can be directly instantiated. Note
   that classes are either abstract or concrete. In addition, once a
   class has been defined as concrete in the hierarchy, all of its
   subclasses MUST also be concrete. It is denoted with a capital C
   (for concrete) near the top-left side of the class.

3.2.1.4.  Container

   A container is an object whose instances may contain zero or more
   additional objects, including container objects. A container
   provides storage, query, and retrieval of its contained objects
   in a well-known, organized way.

3.2.1.5.  PolicyContainer

   In this document, a PolicyContainer is a special type of container
   that provides at least the following three functions:

      1.  It uses metadata to define how its content is interpreted
      2.  It separates the content of the policy from the
          representation of the policy
      3.  It provides a convenient control point for OAM&P operations

   The combination of these three functions enables a PolicyContainer
   to define the behavior of how its constituent components will be
   accessed, queried, stored, retrieved, and how they operate.

   This document does NOT define a specific data type to implementation implement
   a PolicyContainer, as many different types of data types can be
   used. However, the data type chosen SHOULD NOT allow duplicate
   members in the PolicyContainer. In addition, order is irrelevant,
   since priority will override any initial order of the members of
   this PolicyContainer.

3.2.2.  Policy Terminology

   The following terms define different policy concepts used in the
   SUPA Generic Policy Information Model (GPIM). Note that the
   prefix "SUPA" is used for all classes and relationships defined
   in this model to ensure name uniqueness. Similarly, the prefix
   "supa" is defined for all SUPA class attributes.

3.2.2.1.  SUPAPolicyObject

   A SUPAPolicyObject is the root of the GPIM class hierarchy. It is
   an abstract class that all classes inherit from, except the
   SUPAPolicyMetadata class and its subclasses.

3.2.2.2.  SUPAPolicy

   A SUPAPolicy is, in this version of this document, an ECA policy
   rule that is a type of PolicyContainer. The PolicyContainer MUST
   contain an ECA policy rule, a SUPAECAPolicyRule, SHOULD contain one or more
   SUPAPolicyMetadata objects, and MAY contain other elements that
   define the semantics of the policy rule. Policies are generically
   defined as a means to monitor and control the changing and/or
   maintaining of the state of one or more managed objects [1]. In
   this context, "manage" means that one or more of the following six
   fundamental operations are supported: create, read, write, delete,
   start, and stop) [16].

3.2.2.3.  SUPAPolicyClause

   A SUPAPolicyClause is an abstract class. Its subclasses define
   different types of clauses that are used to create the content
   for different types of SUPAPolicies.

   For example, the SUPABooleanClause subclass models the content
   of a SUPAPolicy as a Boolean clause, where each Boolean clause
   is made up of a set of reusable objects. In contrast, a
   SUPAEncodedClause encodes the entire clause as a set of
   attributes. All types of SUPAPolicies MUST use one or more
   SUPAPolicyClauses to construct a SUPAPolicy.

3.2.2.4.  SUPAECAPolicyRule

   An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an
   abstract class that is a type of PolicyContainer. It represents
   a policy rule as a three-tuple, consisting of an event, a
   condition, and an action clause. In an information model, this
   takes the form of three different aggregations, one for each
   clause. Each clause MUST be represented by at least one
   SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain
   zero or more SUPAPolicySources, zero or more SUPAPolicyTargets,
   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

   Metadata is, literally, data about data. SUPAMetadata is an
   abstract class that contains prescriptive and/or descriptive
   information about the object(s) to which it is attached. While
   metadata can be attached to any information model element, this
   document only considers metadata attached to classes and
   relationships.

   When defined in an information model, each instance of the
   SUPAMetadata class MUST have its own aggregation relationship
   with the set of objects that it applies to. However, a data model
   MAY map these definitions to a more efficient form (e.g.,
   flattening the object instances into a single object instance).

3.2.2.6.  SUPAPolicyTarget

   SUPAPolicyTarget is an abstract class that defines a set of
   managed objects that may be affected by the actions of a
   SUPAPolicyClause. A SUPAPolicyTarget may use one or more
   mechanisms to identify the set of managed objects that it
   affects; examples include OIDs and URIs.

   When defined in an information model, each instance of the
   SUPAPolicyTarget class MUST have its own aggregation
   relationship with each SUPAPolicy that uses it. However, a
   data model MAY map these definitions to a more efficient form
   (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and
   SUPAPolicy object instances into a single object instance).

3.2.2.7.  SUPAPolicySource

   SUPAPolicySource is an abstract class that defines a set of
   managed objects that authored this SUPAPolicyClause. This is
   required for auditability and authorization policies, as well
   as some forms of deontic and alethic logic.

   A SUPAPolicySource may use one or more mechanisms to identify the
   set of managed objects that authored it; examples include OIDs and
   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
   SUPAPolicySource class MUST have its own aggregation relationship
   with each SUPAPolicy that uses it. However, a data model MAY map
   these definitions to a more efficient form (e.g., flattening the
   SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances
   into a single object instance).

3.2.3.  Modeling Terminology

   The following terms define different types of relationships used
   in the information models of the SUPA Generic Policy Information
   Model (GPIM).

3.2.3.1.  Inheritance

   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
   (e.g., the superclass). Any attributes and relationships that are
   defined for the superclass are also defined for the subclass.
   However, a subclass does NOT change the characteristics or behavior
   of the attributes or relationships of the superclass that it
   inherits from. Formally, this is called the Liskov Substitution
   Principle [7]. This principle is one of the key characteristics
   that is NOT followed in [4], [6], [RFC3060], and [RFC3460].

   A subclass MAY add new attributes and relationships that refine
   the characteristics and/or behavior of it compared to its
   superclass. A subclass MUST NOT change inherited attributes or
   relationships.

3.2.3.2.  Relationship

   A relationship is a generic term that represents how a first set
   of entities interact with a second set of entities. A recursive
   relationship sets the first and second entity to the same entity.
   There are three basic types of relationships, as defined in the
   subsections below: associations, aggregations, and compositions.

   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
   attributes of a relation that it inherits that is realized using
   an association class (see section 3.2.3.6).

3.2.3.3.  Association

   An association represents a generic dependency between a first
   and a second set of entities. In an information model, an
   association MAY be represented as a class.

3.2.3.4.  Aggregation

   An aggregation is a stronger type (i.e., more restricted
   semantically) of association, and represents a whole-part
   dependency between a first and a second set of entities. Three
   objects are defined by an aggregation: the first entity, the
   second entity, and a new third entity that represents the
   combination of the first and second entities.

   The entity owning the aggregation is referred to as the
   "aggregate", and the entity that is aggregated is referred to as
   the "part".  In an information model, an aggregation MAY be
   represented as a class.

3.2.3.5.  Composition

   A composition is a stronger type (i.e., more restricted
   semantically) of aggregation, and represents a whole-part
   dependency with two important behaviors. First, an instance of the
   part is included in at most one instance of the aggregate at a
   time. Second, any action performed on the composite entity (i.e.,
   the aggregate) is propagated to its constituent part objects.
   For example, if the composite entity is deleted, then all of its
   constituent part entities are also deleted. This is not true of
   aggregations or associations - in both, only the entity being
   deleted is actually removed, and the other entities are unaffected.
   In an information model, a composition MAY be represented as
   a class.

3.2.3.6.  Association Class

   A relationship may be implemented as an association class. This is
   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
   association class, then the attributes of the association class, as
   well as other relationships that the association class participates
   in, may be used to define the semantics of the relationship. If the
   relationship is not implemented as an association class, then no
   additional semantics (beyond those defined by the type of the
   relationship) are expressed by the relationship.

3.2.3.7.  Multiplicity

   A specification of the range of allowable cardinalities that a set
   of entities may assume. This is always a pair of ranges, such as
   1 - 1 or 0..n - 2..5.

3.2.3.8.  Navigability

   A relationship may restrict one object from accessing the other
   object. This document defines two choices:

      1.  Each object is navigable by the other, which is indicated
          by NOT providing any additional symbology, or
      2.  An object A can navigate to object B, but object B cannot
          navigate to object A. This is indicated by an open-headed
          arrow pointing to the object that cannot navigate to the
          other object. An example is shown below:

         +---------+         3..4 +---------+
         |         | 1..2        \|         |
         | Class A |--------------| Class B |
         |         |             /|         |
         +---------+              +---------+

   The above figure shows a navigability restriction. Class A can
   navigate to Class B, but Class B cannot navigate to Class A. This is
   a mandatory association, since none of the multiplicities contain a
   '0'. This association reads as follows:

      Class A depends on 3 to 4 instances of Class B, and
      Class B depends on 1 to 2 instances of Class A.

3.3.  Symbology

   The following symbology is used in this document.

3.3.1.  Inheritance

   Inheritance: a subclass inherits the attributes and relationships
                of its superclass, as shown below:

                        +------------+
                        | Superclass |
                        +------+-----+
                              / \
                               I
                               I
                               I
                        +------+-----+
                        |  Subclass  |
                        +------------+

3.3.2.  Association

   Association: Class B depends on Class A, as shown below:

                                        +---------+      +---------+
        +---------+      +---------+    |         |     \|         |
        | Class A |------| Class B |    | Class A |------| Class B |
        +---------+      +---------+    |         |     /|         |
                                        +---------+      +---------+

           association with no                association with
         navigability restrictions        navigability restrictions

3.3.3.  Aggregation

   Aggregation: Class B is the part, Class A is the aggregate,
                as shown below:

       +---------+                    +---------+         +---------+
       |         |/ \   +---------+   |         |/ \     \|         |
       | Class A | A ---| Class B |   | Class A | A ------| Class B |
       |         |\ /   +---------+   |         |\ /     /|         |
       +---------+                    +---------+         +---------+

           aggregation with no                aggregation with
         navigability restrictions        navigability restrictions

3.3.4.  Composition

   Composition: Class B is the part, Class A is the composite,
                as shown below:

       +---------+                    +---------+         +---------+
       |         |/ \   +---------+   |         |/ \     \|         |
       | Class A | C ---| Class B |   | Class A | C ------| Class B |
       |         |\ /   +---------+   |         |\ /     /|         |
       +---------+                    +---------+         +---------+

            composition with no                composition with
         navigability restrictions        navigability restrictions

3.3.5.  Association Class

   Association Class: Class C is the association class implementing
                      the relationship D between classes A and B
                        +---------+          +---------+
                        | Class A |----+-----| Class B |
                        +---------+    ^     +---------+
                                       |
                                       |
                            +----------+----------+
                            | Association Class C |
                            +---------------------+

3.3.6.  Abstract vs. Concrete Classes

   In UML, abstract classes are denoted with their name in italics.
   For this draft, a capital 'A' will be placed at either the top
   left or right corner of the class to signify that the class is
   abstract. Similarly, a captial 'C' will be placed in the same
   location to represent a concrete class. This is shown below.

                      A                    C
                     +---------+          +---------+
                     | Class A |          | Class B |
                     +---------+          +---------+

                  An Abstract Class     A Concrete Class

4.  Policy Abstraction Architecture

   This section describes the motivation for the policy abstractions that are used in
   SUPA. The following abstractions are provided:

      o The GPIM defines a technology-neutral information model that
        can express the concept of Policy.
          o All classes, except for SUPAPolicyMetadata, inherit from
            SUPAPolicyObject, or one of its subclasses.
          o SUPAPolicyObject and SUPAPolicyMetadata are designed to
            inherit from classes in another model; the GPIM does not
            define an "all-encompassing" model.
      o This version of this document restricts the expression of
        Policy to a set of event-condition-action clauses.
          o Each clause is defined as a Boolean expression, and MAY
            also be defined as a reusable object.
          o Clauses may be combined to form more complex Boolean
            expressions.
      o The purpose of the GPIM is to enable different policies that
        have fundamentally different representations to share common
        model elements. Policy statements, which are implemented as
        instances of the SUPAPolicyClause class, separates separate the content
        of a Policy from its representation. This is supported by:
          o All policy rules (of which SUPAECAPolicyRule is the
            first example of a concrete class) are derived from
            the SUPAPolicyStructure class.
          o All objects that are components of policy rules are
            derived from the SUPAPolicyComponentStructure class.
          o A SUPAPolicy MUST contain at least one SUPAPolicyClause.
          o A SUPAPolicy MAY specify one or more SUPAPolicyTarget,
            SUPAPolicySource, and SUPAPolicyMetadata objects to
            augment the semantics of the SUPAPolicy
      o A SUPAPolicyClause has two subclasses:
          o A SUPABooleanClause, which is used to build
            SUPAECAPolicyRules from reusable objects.
          o A SUPAEncodedClause, which is used for using attributes
            instead of objects to construct a SUPAECAPolicyRule.
      o A SUPAECAPolicyRule defines the set of events and conditions
        that are responsible for executing its actions; it MUST have
        at least one event clause, at least one condition clause, and
        at least one action clause.
          o The action(s) of a SUPAECAPolicyRule are ONLY executed
            if both the event and condition clauses evaluate to TRUE
          o A SUPAPolicyAction MAY invoke another SUPAPolicyAction in
            another SUPAECAPolicyRule (see section 6.13).
      o SUPAMetadata MAY be defined for any SUPAPolicyObject class.
      o SUPAMetadata MAY be prescriptive and/or descriptive in nature.

   This model, and its abstractions, define an interoperable
   representation of policies that can be communicated between
   different actors. Generation and execution of these policies
   is beyond the scope of this document.

4.1.  Motivation

   The power of policy management is its applicability to many
   different types of systems. There are many different actors that
   can use a policy management system, including end-users, operators,
   application developers, and administrators. Each of these
   constituencies have different concepts and skills, and use
   different terminology. For example, an operator may want to express
   an operational rule that states that only Platinum and Gold users
   can use streaming multimedia applications. As a second example, a
   network administrator may want to define a more concrete policy
   rule that looks at the number of dropped packets and, if that
   number exceeds a programmable threshold, changes the queuing and
   dropping algorithms used.

   SUPA may be used to define other types of policies, such as for
   systems and operations management; an example is: "All routers and
   switches must have password login disabled". See section 3 of [8]
   for additional declarative and ECA policy examples.

   All of the above examples are commonly referred to as "policy
   rules", but they take very different forms, since they are at very
   different levels of abstraction and typically authored by
   different actors. The first was very abstract, and did not contain
   any technology-specific terms, while the second was more concrete,
   and likely used technical terms of a general (e.g., IP address
   range, port numbers) as well as a vendor-specific nature (e.g.,
   specific queuing, dropping, and/or scheduling algorithms
   implemented in a particular device). The third restricted the type
   of login that was permissible for certain types of devices in the
   environment.

   Note that the first two policy rules could directly affect each
   other. For example, Gold and Platinum users might need different
   device configurations to give the proper QoS markings to their
   streaming multimedia traffic. This is very difficult to do if a
   common policy model does not exist, especially if the two policies
   are authored by different actors that use different terminology
   and have different skill sets. More importantly, the users of
   these two policies likely have different job responsibilities.
   They may have no idea of the concepts used in each policy. Yet,
   their policies need to interact in order for the business to
   provide the desired service. This again underscores the need for
   a common policy framework.

   Certain types of policy rules (e.g., ECA) may express actions, or
   other types of operations, that contradict each other. SUPA
   provides a rich object model that can be used to support language
   definitions that can find and resolve such problems.

   Models built using this IM are intended primarily for communicating
   policy, not for executing policy.

4.2.  SUPA Approach

   The purpose of the SUPA Generic Policy Information Model (GPIM) is
   to define a common framework for expressing policies at different
   levels of abstraction. SUPA uses the GPIM as a common vocabulary
   for representing policy concepts that are independent of language,
   protocol, repository, and level of abstraction. This enables
   different actors to author and use policies at different levels of
   abstraction. This forms a policy continuum [1] [2], where more
   abstract policies can be translated into more concrete policies,
   and vice-versa.

   Most systems define the notion of a policy as a single entity.
   This assumes that all users of policy have the same terminology,
   and use policy at the same level of abstraction. This is rarely,
   if ever, true in modern systems. The policy continuum defines a
   set of views (much like RM-ODP's viewpoints [9]) that are each
   optimized for a user an actor playing a specific role. SUPA defines the
   GPIM as a standard vocabulary and set of concepts that enable
   different actors to use different formulations of policy. This
   corresponds to the different levels in the policy continuum, and
   as such, can make use of previous experience in this area.

   It may be necessary to translate a Policy from a general to a more
   specific form (while keeping the abstraction level the same). For
   example, the declarative policy "Every network attached to a VM
   must be a private network owned by someone in the same group as
   the owner of the VM" may be translated to a more formal form (e.g.,
   Datalog (as
   into Datalog, as in OpenStack Congress). It may also be necessary
   to translate a Policy to a different level of abstraction. For
   example, the previous Policy may need to be translated to a form
   that network devices can process directly. This requires a common
   framework for expressing policies that is independent of the level
   of abstraction that a Policy uses.

4.3.  SUPA Generic Policy Information Model Overview

   Figure 2 illustrates the approach for representing policy rules
   in SUPA. The top two layers are defined in this document; the
   bottom layer (Data Models) are defined in separate documents.
   Conceptually, the GPIM

4.2.1.  Design Patterns

   A design pattern defines a set of objects that define the
   key elements of reusable solution to a Policy independent of how it commonly occuring
   software design problem. It is represented or not a finished solution, because of
   its content. As will be shown, there generic nature. Rather, it is a significant difference
   between SUPAECAPolicyRules (see Section 6) and other types of
   policies (see Section 7). "template" that outlines how to
   solve a problem that occurs in many different situations.

   In principle, other types of SUPAPolicies
   could be defined, but the current charter is restricted order to using
   only event-condition-action SUPAPolicies as exemplars.

   Note: provide internal and external consistency, the GPIM MAY be used without the EPRIM. However, in order to
   use the EPRIM, the GPIM MUST also be used.

           +----------------------------------------------+
           | SUPA Generic Policy Information Model (GPIM) |
           +----------------------+-----------------------+
                                 / \
                                  |
                                  |
                +-----------------+--------------+
                |                                |
                |                                |
    +-----------+---------------+  +-------------+-------------+
    |    SUPAECAPolicyRule      |  | Other Policy Models that  |
    |
   Information Model (EPRIM) |  | are Derived from uses several design patterns in key places withinhe
   the GPIM |
    +-----------+---------------+  +-------------+-------------+
               / \                              / \
                |                                |
                |                                |
    +-----------+-----------+        +-----------+------------+
    |     ECAPolicyRule     |        |    Other Types of      |
    |       Data Model      |        |      Data Models       |
    +-----------------------+        +------------------------+

          Figure 2.  Overview model. The following sub-sections describe three of SUPA Policy Rule Abstractions

   This draft defines the GPIM design
   patterns that this model uses.

4.2.1.1.  Composite Pattern

   One common issue is that some classes may need to be able to contain
   other classes. A common analogy is a folder system - folders can
   contain folders and EPRIM. files, but (typically) files do not contain
   folders. This draft further assumes
   that is addressed by the SUPA Information Model Composite Pattern.

   The Composite Pattern creates a minimum of two subclasses, one for
   representing objects that can stand alone (e.g., files), and one for
   representing objects that serve as collections (e.g., folders). An
   example of this is SUPAECAPolicyRule. The composite subclass (e.g.,
   SUPAECAPolicyRuleComposite) has an aggregating association back to
   or from the parent class (e.g., SUPAECAPolcyRule). This allows one
   to have composite entities which are made up of either the GPIM other
   composites, or the
   combination any of the GPIM and the EPRIM. Extensions atomic subclasses (e.g.,
   SUPAECAPolicyRuleAtomic).

   While some models use recursive associations for this, experience
   has shown that this causes inappropriate associations, such as
   leading to both an atomic subclass being able to contain more complex
   instances of the GPIM
   and parent class.

4.2.1.2.  Decorator Pattern

   Another common issue is the EPRIM need to have a highly extensible set of
   additional information that MAY need to be added for certain object
   instances. Some of this can be made as long as these extensions do not
   conflict done with metadata, but often, the content and structure defined in the GPIM and
   EPRIM. If the GPIM and EPRIM are part of another
   information model,
   then they should collectively still define to be added forms a single information
   model. The GPIM defines part of the following concepts:

     o object instance behavior.
   This is addressed by the decorator pattern [11]. A class defining good example is
   SUPAPolicyClause, whose definition and behavior can be extended
   dynamically at runtime by wrapping its object instance with
   other objects. This is explained below.

   An aggregation is defined between SUPAPolicyClause and the top
   superclass of the GPIM class hierarchy, called
       SUPAPolicyObject
     o Four subclasses set of SUPAPolicyObject, representing:
        o classes that form the top Decorator Pattern
   (i.e., SUPAPolicyClauseComponentDecorator). This aggregation
   enables zero or more concrete subclasses of the Policy hierarchy, called
          SUPAPolicyStructure
        o
   SUPAPolicyClauseComponentDecorator class to "wrap" (i.e., be
   attached to) the top instance of the Policy component hierarchy, called
          SUPAPolicyComponentStructure
        o PolicySource
        o PolicyTarget

   The SUPAPolicyStructure class is the superclass for all types of
   Policies (e.g., imperative, declarative, and others). being decorated (i.e.,
   SUPAPolicyClause in this example). This
   document is currently limited to imperative (e.g., ECA) policies.
   However, care has been taken the effect of creating a
   new object that appears to ensure be a SUPAPolicyClause, but contains new
   attributes and behavior that are added to the existing attributes
   and
   relationships behavior of the SUPAPolicyStructure class SUPAPolicyClause. Clients that are extensible,
   and can be used for more types of policies than just ECA policies.

   This yields using the following high-level structure:

                     A
                    +------------------+
                    | SUPAPolicyObject |
                    +--------+---------+
                            / \
                             I
                             I
            +----------------+--------------------+
            I                I                    I
    A       I                I        A           I
   +--------+------------+   I       +------------+-----------------+
   | SUPAPolicyStructure |   I       | SUPAPolicyComponentStructure |
   +----+----------------+   I       +------------+-----------------+
       / \                   I                   / \
        I           +--------+----+               I
        I           I             I               I
        I    C      I             I               I
        I   +-------+----------+  I               I
        I   | SUPAPolicySource |  I               I
        I   +------------------+  I               I
        I                         I               I
        I           +-------------+               I
        I           I                       +-----+-------+
        I    C      I                       I             I
        I   +-------+----------+    A       I             I
        I   | SUPAPolicyTarget |   +--------+---------+   I
        I   +------------------+   | SUPAPolicyClause |   I
   A    I                          +------------------+   I
  +-----+------------+                                    I
  | SUPAECAPolicyRule|                A                   I
  +------------------+               +--------------------+---------+
                                     | SUPAPolicyComponentDecorator |
                                     +------------------------------+

          Figure 3.  Functional View
   decorated object (i.e., SUPAPolicyClause) are **not** aware of the Top-Level GPIM

   Note
   these changes.

   The SUPAPolicyClauseComponentDecorator class has a number of
   specific subclases that all classes except the SUPAPolicySource and the
   SUPAPolicyTarget classes are defined as abstract. This provides
   more freedom for the data modeler in implementing the data model.
   For example, if the data model uses an object-oriented language,
   such as Java, then the above structure enables all each represent additional kinds of the abstract
   classes to
   information that can be collapsed into attached to a single concrete class. If SUPAPolicyClause object
   instance. In this is
   done, attributes as well as relationships are inherited.

4.3.1.  SUPAPolicyObject

   A SUPAPolicyObject serves as a single root of the SUPA system
   (i.e., all other classes in the model are example, concrete subclasses of the
   SUPAPolicyObject class) except for the Metadata objects, which are
   in a separate class hierarchy. This simplifies code generation SUPAPolicyTerm
   and
   reusability. It also enables SUPAPolicyMetadata objects to SUPAECAComponent, along with SUPAPolicyCollection and other
   subclasses, define optional information that can be attached to any appropriate a
   SUPAPolicyClause. More specifically, each concrete subclass of SUPAPolicyObject.

4.3.2.  SUPAPolicyStructure

   SUPAPolicyStructure is an abstract superclass that is the base
   SUPAPolicyClause class for defining different types of policies (however, in this
   version of this document, only ECA policy rules are modeled). It
   serves as a convenient aggregation point to define atomic (i.e.,
   individual policies that can be used independently) and composite
   (i.e., hierarchies decorated by each concrete subclass of policies) SUPAPolicies; it also enables
   PolicySources and/or PolicyTargets
   the SUPAPolicyClauseComponentDecorator class. This means that the
   SUPAPolicyClauseComponentDecorator object has an instance variable
   that holds a reference to be associated with a given
   set of Policies.

   SUPAPolicies are defined SUPAPolicyClause object. Since the
   SUPAPolicyClauseComponentDecorator object has the same interface as either a stand-alone PolicyContainer
   or a hierarchy of PolicyContainers. A PolicyContainer specifies
   the structure, content, and optionally, source, target, and
   metadata information for a SUPAPolicy. This is implemented by SUPAPolicyClause object, the
   subclasses SUPAPolicyClauseComponentDecorator
   class (and all of SUPAPolicyStructure. For example, the composite
   pattern is used its subclasses) are transparent to create two subclasses clients of the SUPAECAPolicyRule
   class; SUPAECAPolicyRuleAtomic is used for stand-alone policies,
   and SUPAECAPolicyRuleComposite is used
   SUPAPolicyClause class (and its subclasses). Hence, all
   SUPAPolicyClauseComponentDecorator object instances can add
   attributes and/or methods to build hierarchies the concrete instance of
   policies.

   This document defines a SUPAPolicy as an ECA Policy Rule, though the GPIM enables other types chosen
   subclass of policies SUPAPolicyClause.

   Figure 2 shows how this is done for methods.
     - Figure 2a shows the initial object to be defined and used
   with an ECA policy rule. The GPIM model is used in [2] and [5],
   along with extensions that allow [2] and [5] to define multiple
   types of policies that are derived from wrapped
     - Figure 2b shows the GPIM. They also allow
   different combinations of different types of policy rules to be
   used with each other. Most previous work cannot define different
   types of policy rules; please see Appendix A for a comparison to
   previous work.

4.3.3.  SUPAPolicyComponentStructure

   SUPAPolicyComponentStructure is an abstract superclass that is SUPAPolicyEvent object wrapping the
   base class for defining components of different types of policies.
   SUPAPolicyStructure subclasses define
       SUPAEncodedClause object
     - Figure 2c shows SUPAGenericDecoratedComponent object
       wrapping the structure SUPAPolicyEvent object.

      +-------------------+
      | SUPAEncodedClause |
      |   eval()          |   ===>
      +-------------------+
     (a)  Initial Object

                 +------------------------+
                 |  SUPAPolicyEvent       |
                 |    eval()              |
                 | +-------------------+  |
                 | | SUPAEncodedClause |  | ===>
                 | |     eval()        |  |
                 | +-------------------+  |
                 +------------------------+
     (b)  SUPAPolicyEvent "wraps" SUPAEncodedClause

                            +--------------------------------+
                            |  SUPAGenericDecoratedComponent |
                            |    eval()                      |
                            |   +-----------------------+    |
                            |   | SUPAPolicyEvent       |    |
                            |   |   eval()              |    |
                            |   | +-------------------+ |    |
                            |   | | SUPAEncodedClause | |    |
                            |   | |    eval()         | |    |
                            |   | +-------------------+ |    |
                            |   +-----------------------+    |
                            +--------------------------------+
     (c)  SUPAGenericDecoratedComponent "wraps" SUPAPolicyEvent

       Figure 2.  Conceptual Depiction of a policy,
   while SUPAPolicyComponentStructure subclasses define eval() Decorated Method

   When the content
   that eval() method is contained called in the structure outermost object
   (SUPAGenericDecoratedComponent), it delegates to the eval() method
   of a policy. For example, a
   SUPAECAPolicyRule is an imperative policy rule, SUPAPolicyEvent, which in turn delegates to the eval() method
   of SUPAEncodedClause. This method executes and defines its
   structure; its event, condition, returns the
   results to SUPAPolicyEvent, which executes and action clauses are populated
   by SUPAPolicyComponentStructure subclasses. The strength of this
   design is that different types of policies (e.g., imperative returns the results
   to SUPAGenericDecoratedComponent, which executes and
   declarative policies) can returns the
   final result.

   In addition, decorators may be represented applied to decorators. This is
   accomplished by using a common set concrete subclass of
   policy components.

   Please see Appendix for a comparison to previous work.

4.3.4.  SUPAPolicyClause

   All policies derived from the GPIM are made up of one or more
   SUPAPolicyClauses, decorating classes
   (SUPAPolicyComponentDecorator), which define the content then decorates a concrete
   subclass of the Policy. parent decorator (i.e.,
   SUPAPolicyClauseComponentDecorator). This enables a Policy of one type (e.g., ECA) to invoke Policies
   of the same basic
   information to have either individual decorations or different types. SUPAPolicyClause is an abstract
   class, complex
   decorator aggregates.

4.2.2.  Association Classes

   An association class enables attributes, operations, and serves as a convenient aggregation point for assembling other objects that make up a SUPAPolicyClause.

   The GPIM defines a single concrete subclass of SUPAPolicyClause,
   called SUPAEncodedClause. This is a generic clause, and can
   features to be
   used by any type of Policy in a stand-alone fashion. It added to an association. Consider the following
   example.  An Employee can also
   be used work for a Company, in conjunction with other SUPAPolicyClauses. The EPRIM
   also defines which case the
   Company pays the Employee a subclass of SUPAPolicyClause; see section 6.7).

   The structure salary. Now, where do you define the
   salary attribute? If you define the salary as part of the GPIM is meant to provide Company,
   then every Employee gets the same salary. If you define salary as
   an extensible
   framework for defining different types attribute of policies. This is
   demonstrated by Employee, then that Employee gets the EPRIM (see section 6) and same salary
   for all Companies that the LSIM (see Employee works for.

   These problems result from the
   Appendices) fact that each define new subclasses of SUPAPolicyClause
   (i.e., SUPABooleanClause different Employees can
   work for the same Company, and SUPALogicClause, respectively)
   without defining new classes that have no GPIM superclass.

   A SUPAPolicyClause is defined as an object. Therefore, clauses and
   sets of clauses are objects, which promotes reusability.

4.3.5.  SUPAPolicyComponentDecorator

   One of the problems in building a policy model is Employee may also work for
   different Companies. Hence, the tendency salary paid to
   have the Employee is in
   reality a multitude of classes, and hence object instances, to
   represent different combinations function of policy events, conditions, and
   actions. This can lead to class and/or the relationship explosion.
   Please see Appendix A between Employee and
   Company, since the salary changes when the Employee works for a comparison to previous work.

   SUPAPolicyClauses are constructed using the Decorator Pattern
   [11].
   different Company. This is a design pattern shown in Figure 3.

         C                           C
        +----------+ 1..n      0..n +---------+
        |          |  IsEmployedBy  |         |
        | Employee +--------+-------+ Company |
        |          |        ^       |         |
        +----------+        |       +---------+
                            |
                     C      |
                   +--------+-----------+
                   | IsEmployedByDetail |
                   |                    |
                   |  salary : Float    |
                   |                    |
                   +--------------------+

             Figure 3.  Using Association Classes

   Figure 3 shows that enables behavior a class, named IsEmployedByDetail, is used to
   represent the semantics of the IsEmployedBy association.

   Note that an association class can define its own (i.e., class-
   level) attributes, methods, and relationships; all of these can be
   selectively added
   used to an individual object, either statically or
   dynamically, without affecting define the behavior intended semantics of other objects from the same association class. The decorator pattern uses composition, instead of
   inheritance, to avoid class
   Note: class-level attributes, methods, and relationships are often
   called **static** attributes, methods, and relationships.
   Examples include:

     o restrict when the relationship explosion. The
   decorator pattern also enable new objects to can be composed from
   parts or all established and/or
       terminated
     o restrict which classes of one end of existing objects without affecting the existing
   objects.

   This enables the resulting SUPAPolicyClause to relationship can be constructed
   completely
       associated with which classes from objects the other end of the
       relationship
     o define attributes that depend on both classes in the SUPA information model. This
   facilitates
       relationship

   In the construction above example, the use of policies at runtime by a machine. class enables the attributes of
   the association class (i.e., IsEmployedByDetail) to be used to
   define the salary attribute. This is also true because the salary attribute is
   a function of [2] both the particular Employee being paid the salary
   and [5]; however, the Company that the Employee works for. In this is NOT true of
   most other models. Please see Appendix A for a comparison example, we
   have chosen to
   previous work.

   SUPAPolicyComponentDecorator defines four types give the salary attribute a datatype of objects that type Float.

   Optionally, the association class can be used subclassed to form a SUPAPolicyClause. Each object may refine
   additional behavior. In addition, the association class can have
   its own set of relationships; these relationships could be used
   with all
   make the attributes of the association class dependent on
   other objects, if desired. classes.

4.3.  SUPA Generic Policy Information Model Overview

   Figure 5 illustrates the approach for representing policy rules
   in SUPA. The first three top two layers are defined in this document; the GPIM, with the last
   bottom layer (Data Models) are defined in separate documents.
   Conceptually, the EPRIM. The GPIM defines a set of objects are:

      o SUPAPolicyTerm, which enables that define the
   key elements of a clause to Policy independent of how it is represented or
   its content. As will be defined in a
        canonical {variable, operator, value} form
      o SUPAGenericDecoratedComponent, which enabled shown, there is a custom object
        to be defined significant difference
   between SUPAECAPolicyRules (see Section 6) and then used in a SUPAPolicyClause
      o SUPAPolicyCollection, which enables a collection other types of objects
        to be gathered together and associated with all or a portion
   policies (see Section 7). In principle, other types of a SUPAPolicyClause
      o SUPAECAComponent, which defines Events, Conditions, and
        Actions as reusable objects

   This approach facilitates SUPAPolicies
   could be defined, but the machine-driven construction of
   policies. Note that this current charter is completely optional; policies do not
   have restricted to use these constructs.

4.3.6.  SUPAPolicyTarget

   A SUPAPolicyTarget is a set of managed entities that a SUPAPolicy
   is applied to. A managed entity can using
   only be designated a
   SUPAPolicyTarget if it can process actions from a SUPAPolicy.

   A managed object may not be in a state that enables management
   operations to be performed on it. Furthermore, the policy-based
   management system SHOULD ensure that the management entity
   performing event-condition-action SUPAPolicies as exemplars.

   Note: the management operations has GPIM MAY be used without the proper permissions EPRIM. However, in order to
   perform
   use the management operations. The design of EPRIM, the
   SUPAPolicyTarget addresses both of these criteria.

4.3.7.  SUPAPolicySource

   A SUPAPolicySource is a set of managed entities GPIM MUST also be used.

           +----------------------------------------------+
           | SUPA Generic Policy Information Model (GPIM) |
           +----------------------+-----------------------+
                                 / \
                                  |
                                  |
                +-----------------+--------------+
                |                                |
                |                                |
    +-----------+---------------+  +-------------+-------------+
    |    SUPAECAPolicyRule      |  | Other Policy Models that authored, or  |
    | Information Model (EPRIM) |  | are otherwise responsible for, this SUPAPolicy. Note that a
   SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its
   primary use is for auditability and Derived from the implementation GPIM |
    +-----------+---------------+  +-------------+-------------+
               / \                              / \
                |                                |
                |                                |
    +-----------+-----------+        +-----------+------------+
    |     ECAPolicyRule     |        |    Other Types of deontic
   and/or alethic logic.

4.4.  The Design      |
    |       Data Model      |        |      Data Models       |
    +-----------------------+        +------------------------+

          Figure 5.  Overview of SUPA Policy Rule Abstractions

   This draft defines the GPIM and EPRIM. This section describes draft further assumes
   that the overall design SUPA Information Model is made up of either the GPIM.

   The GPIM defines a policy as a type or the
   combination of PolicyContainer. For this
   version, only ECA Policy Rules will be described. However, it
   should be noted that the mechanism described is applicable GPIM and the EPRIM. Extensions to
   other types of policies (e.g., declarative) both the GPIM
   and the EPRIM can be made as well.

4.4.1.  Structure of Policies

   Recall that a PolicyContainer was defined long as a special type these extensions do not
   conflict with the content and structure defined in the GPIM and
   EPRIM. If the GPIM and EPRIM are part of
   container that provides at least another information model,
   then they should collectively still define a single information
   model. The GPIM defines the following three functions:

      1.  It uses metadata to define how its content is described
          and/or prescribed
      2.  It separates concepts:

     o A class defining the content top of the policy from GPIM class hierarchy, called
       SUPAPolicyObject
     o Four subclasses of SUPAPolicyObject, representing:
        o the
          representation top of the policy
      3.  It provides a convenient control point for OAMP operations. Policy hierarchy, called
          SUPAPolicyStructure
        o the top of the Policy component hierarchy, called
          SUPAPolicyComponentStructure
        o PolicySource
        o PolicyTarget

   The first requirement SUPAPolicyStructure class is provided by the ability superclass for any subclass all types of Policy (the root of the information model) to aggregate one or
   more concrete instances of a SUPAPolicyMetadata class.
   Policies (e.g., imperative, declarative, and others). This
   document is
   explained in detail in section 5.2.2.

   The second requirement is met by representing an ECA Policy as
   having two parts: (1) a rule part and (2) components currently limited to imperative (e.g., ECA) policies.
   However, care has been taken to ensure that make up the rule. Since functional attributes and declarative policies are not,
   strictly speaking, "rules", the former is named PolicyStructure,
   while the latter is named PolicyComponentStructure.

   The third requirement is met by the concrete subclasses of
   PolicyStructure. Since they are PolicyContainers, they are made
   up
   relationships of the SUPAECAPolicyRule, its commponents, SUPAPolicyStructure class are extensible,
   and any metadata
   that applies to the PolicyContainer, the SUPAECAPolicyRule, and.or
   any components can be used for more types of the SUPAECAPolicyRule. policies than just ECA policies.

   This provides optional
   low-level control over any part of the SUPAECAPolicyRule.

   The above requirements result in yields the design shown in Figure 4.

  A                     SUPAHasPolicyMetadata following high-level structure:

                     A
 +------------------+/ \                      \+--------------------+
                    +------------------+
                    | SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata |
 +---------+--------+\ /                      /+--------------------+
                    +--------+---------+
                            / \        0..n                  0..n
                             I
                             I
           +------+------------------------------------+
            +----------------+--------------------+
            I                I                    I
    A       I                I        A           I
   +--------+------------+    +------------------+-----------+   I       +------------+-----------------+
   | SUPAPolicyStructure |   I       | SUPAPolicyComponentStructure |
         +--------+------------+    +-------------+----------------+
   +----+----------------+   I       +------------+-----------------+
       / \                   I                   / \
        I           +--------+----+               I
        I           I             I               I
        I    C      I             I               I
        I   +-------+----------+  I               I
        I
          (subclasses representing        (subclasses representing
        different types of policies)    different policy components)

                      Figure 4.  Structure of a Policy

   Note that aggregation in Figure 4 (named SUPAHasPolicyMetadata)
   is realized as an association class, in order to manage which set
   of Metadata can be aggregated by which SUPAPolicyObject. The
   combination of these three functions enables a PolicyContainer
   to define the behavior of how its constituent components will be
   accessed, queried, stored, retrieved, and how they operate.

   It is often necessary to construct groups of policies. The GPIM
   follows [2] and [5], and uses the composite pattern [11] to
   implement this functionality, as shown in Figure 5 below. There
   are a number of advantages to using the composite pattern over a
   simple relationship, as detailed in [11].

   Figure 5 shows that SUPAPolicyStructure has a single subclass,
   called SUPAECAPolicyRule. Note, however, that other types of
   policies, such as declarative policies, can be defined as
   subclasses of SUPAPolicyStructure in the future.

                               A
                              +---------------------+   | SUPAPolicyStructure SUPAPolicySource |
                              +--------+------------+
                                      / \  I               I
                       +---------------+----------------+
        I   +------------------+  I               I
        I                         I               I
        I           +-------------+               I
        I           I                       +-----+-------+
        I    C      I                       I             I
        I   +-------+----------+    A       I
      +----------------+---------------+    +-----------+-----------+             I
        I   | Future Subclasses to Represent SUPAPolicyTarget |   +--------+---------+   I
        I   +------------------+   |   SUPAECAPolicyRule SUPAPolicyClause |   I
   A    I                          +------------------+   I
  +-----+------------+                                    I
  |  Represent Different Policies SUPAECAPolicyRule|          A                         I
  +------------------+         +--------------------------+---------+
                               |    +-----------------------+
      +--------------------------------+ SUPAPolicyClauseComponentDecorator |
                               +------------------------------------+

          Figure 5.  The Composite Pattern Applied to SUPAPolicyStructure

4.4.2.  Representing an ECA Policy Rule

   An ECA policy rule is a 3-tuple, which is made up of an event
   clause, a condition clause, and an action clause. Each of these
   three types of clauses may in turn be made up of a Boolean
   combination of clauses 6.  Functional View of the Top-Level GPIM

   Note that type. Each clause may be viewed as
   a predicate, all classes except the SUPAPolicySource and the
   SUPAPolicyTarget classes are defined as it abstract. This provides a TRUE or FALSE output. The canonical
   form
   more freedom for the data modeler in implementing the data model.
   For example, if the data model uses an object-oriented language,
   such as Java, then the above structure enables all of the abstract
   classes to be collapsed into a clause single concrete class. If this is
   done, attributes as well as relationships are inherited.

4.3.1.  SUPAPolicyObject

   A SUPAPolicyObject serves as a 3-tuple single root of the form "variable operator value",
   and can be made into more complex Boolean expressions. For example, SUPA system
   (i.e., all other classes in the SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two
   clauses, "(A AND B)" and "(C OR D)", that model are combined together
   using subclasses of the operators OR and NOT.

   A SUPAECAPolicyRule is defined (in
   SUPAPolicyObject class) except for the EPRIM) as an abstract Metadata objects, which are
   in a separate class hierarchy. This simplifies code generation and
   reusability. It also enables SUPAPolicyMetadata objects to be
   attached to any appropriate subclass of SUPAPolicyStructure.

     A                                   A
    +---------------------------+       +------------------+
    | SUPAPolicyObject.

4.3.2.  SUPAPolicyStructure    |       | SUPAPolicyClause |
    +---------+---------+-------+       +--------+----+----+
             / \       / \ 0..1            1..n / \  / \
              I         A                        |    I
              I        \ /                       |    I
              I         |                        |    I
              I         |  SUPAHasPolicyClause   |    I
              I         +------------------------+    I
        A     I                             A         I
       +------+------------+               +----------+-------+
       | SUPAECAPolicyRule |               | SUPAPolicyClause |
       +-------------------+               +------------------+

      Figure 6.  SUPAECAPolicyRule Aggregating SUPAPolicyClauses

   Note

   SUPAPolicyStructure is an abstract superclass that is the aggregation SUPAHasPolicyClause base
   class for defining different types of policies (however, in Figure 6 is
   realized this
   version of this document, only ECA policy rules are modeled). It
   serves as an association class, in order a convenient aggregation point to manage which set
   of SUPAPolicyClauses define atomic (i.e.,
   individual policies that can be aggregated by which used independently) and composite
   (i.e., hierarchies of policies) SUPAPolicies; it also enables
   PolicySources and/or PolicyTargets to be associated with a given
   set of
   SUPAECAPolicyRules. Policies.

   SUPAPolicies are defined as either a stand-alone PolicyContainer
   or a hierarchy of PolicyContainers. A PolicyContainer specifies
   the structure, content, and optionally, source, target, and
   metadata information for a SUPAPolicy. This aggregation is defined at implemented by the
   SUPAPolicyStructure level,
   subclasses of SUPAPolicyStructure. For example, the composite
   pattern is used to create two subclasses of the SUPAECAPolicyRule
   class; SUPAECAPolicyRuleAtomic is used for stand-alone policies,
   and not at SUPAECAPolicyRuleComposite is used to build hierarchies of
   policies.

   This document defines a SUPAPolicy as an ECA Policy Rule, though
   the lower level GPIM enables other types of
   SUPAECAPolicyRule, so policies to be defined and used
   with an ECA policy rule. The GPIM model is used in [2] and [5],
   along with extensions that non-ECA allow [2] and [5] to define multiple
   types of policies can that are derived from the GPIM. They also use this
   aggregation.

   Since allow
   different combinations of different types of policy rules to be
   used with each other. Most previous work cannot define different
   types of policy rules; please see Appendix A for a SUPAECAPolicyRule consists comparison to
   previous work.

4.3.3.  SUPAPolicyComponentStructure

   SUPAPolicyComponentStructure is an abstract superclass that is the
   base class for defining components of three SUPAPolicyClauses,
   at least three separate instances different types of policies.
   SUPAPolicyStructure subclasses define the SUPAHasPolicyClause
   aggregation are instantiated in order to make structure of a complete
   SUPAECAPolicyRule, as shown in Figure 7.

       A                                   A
      +-------------------+               +--------------------+
      | SUPAECAPolicyRule |               |  SUPAPolicyClause  |
      +--+----+----+------+               +-------+----+----+--+
        / \  / \  / \  1..n               0..n   / \  / \  / \
         A    A    A                              |    |    |
        \ /  \ /  \ /                             |    |    |
         |    |    |                              |    |    |
         |    |    |  SUPAHasPolicyClause #1      |    |    |
         |    |    +------------------------------+    |    |
         |    |                                        |    |
         |    |         SUPAHasPolicyClause #2         |    |
         |    +----------------------------------------+    |
         |                                                  |
         |                SUPAHasPolicyClause #3            |
         +--------------------------------------------------+

     note: all 3 aggregations have a multiplicity policy,
   while SUPAPolicyComponentStructure subclasses define the content
   that is contained in the structure of 1..n - 0..n

         Figure 7.  Instantiating a SUPAECAPolicyRule, part 1

   In figure 7, policy. For example, a
   SUPAECAPolicyRule is shown as "owning" these three
   aggregations, since it inherits them from an imperative policy rule, and defines its
   structure; its superclass
   (SUPAPolicyStructure). The three aggregations represent the event, condition, and action clauses are populated
   by SUPAPolicyComponentStructure subclasses. The strength of a SUPAECAPolicyRule.
   Note this
   design is that each of these clauses MAY consist of one or more
   SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist different types of one or more predicates. In this way, complex event, condition, policies (e.g., imperative and action clauses, which are combinations of Boolean expressions
   that form
   declarative policies) can be represented using a logical predicate) are supported, without having to
   define additonal objects (as is done in previous work; please common set of
   policy components.

   Please see the Appendix A for a comparison to previous work.

   The multiplicity of

4.3.4.  SUPAPolicyClause

   All policies derived from the SUPAHasPolicyClause aggregation is
   0..n on GPIM are made up of one or more
   SUPAPolicyClauses, which define the aggregate side and 1..n on content of the part side. Policy.
   This means
   that enables a particular SUPAECAPolicyRule MUST aggregate at least Policy of one
   SUPAPolicyClause, type (e.g., ECA) to invoke Policies
   of the same or different types. SUPAPolicyClause is an abstract
   class, and that serves as a given SUPAPolicyClause MAY be
   aggregated by zero or more SUPAECAPolicyRule objects.

   This cardinality MAY be refined to 3..n convenient aggregation point for SUPAECAPolicyRules,
   since assembling
   other objects that make up a SUPAECAPolicyRule MUST have at least three separate clauses.
   However, since SUPAPolicyClause.

   The GPIM defines a SUPAPolicyStructure is the owner single concrete subclass of this
   aggregation (which is inherited by SUPAECAPolicyRule), the
   cardinality SUPAPolicyClause,
   called SUPAEncodedClause. This is defined to be 1..n on the part side because other
   types of Policies have different needs. The 0..n cardinality
   means that a SUPAPolicyClause may generic clause, and can be aggregated
   used by zero or more
   SUPAECAPolicyRules. The zero is provided so that SUPAPolicyClauses any type of Policy in a stand-alone fashion. It can also
   be stored used in (for example) conjunction with other SUPAPolicyClauses. The EPRIM
   also defines a repository before subclass of SUPAPolicyClause; see section 6.7).

   The structure of the
   SUPAECAPolicyRule GPIM is created; the "or more" recognizes the fact
   that multiple SUPAECAPolicyRules could aggregate meant to provide an extensible
   framework for defining different types of policies. This is
   demonstrated by the same
   SUPAPolicyClause.

   In Figure 7, suppose that SUPAHasPolicyClause#1, #2, EPRIM (see section 6) and #3
   represent the aggregations for LSIM (see the event, condition, and action
   clauses, respectively. This means
   Appendices) that each define new subclasses of these
   SUPAHasPolicyClause aggregations must explicitly identify the
   type of clause SUPAPolicyClause
   (i.e., SUPABooleanClause and SUPALogicClause, respectively)
   without defining new classes that it represents.

   In looking at Figure 7, there is have no difference between any of the
   three aggregations, except for the type of clause that the
   aggregation represents (i.e., event, condition, or action clause).

   Therefore, three different aggregations, each with their own
   association class, is not needed. Instead, the GPIM defines a
   single aggregation (SUPAHasPolicyClause) that is realized using a
   (single) abstract association class (SUPAHasPolicyClauseDetail);
   this association class superclass.

   A SUPAPolicyClause is then subclassed into three concrete
   subclasses, one each to represent the semantics for defined as an event,
   condition, object. Therefore, clauses and action clause.

   The policy management system may use any number of different
   software mechanisms, such as introspection or reflection, to
   determine the nature
   sets of the aggregation (i.e., what object types clauses are being aggregated) in order to select the appropriate subclass
   of SUPAHasPolicyClauseDetail. The three subclasses objects, which promotes reusability.

4.3.5.  SUPAPolicyClauseComponentDecorator

   One of
   SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail,
   SUPAHasPolicyConditionDetail, and SUPAHasPolicyActionDetail,
   respectively. While Event, Condition, and Action objects are
   typically used in ECA policy rules, the design in this document
   enables them to be used as policy components of other types of
   policies as well. This is shown problems in Figure 8.

        A                               A
       +-------------------+           +------------------+
       | SUPAECAPolicyRule |           | SUPAPolicyClause |
       +---------+---------+           +----------+-------+
                / \ 1..n                    0..n / \
                 A                                |
                \ /                               |
                 |                                |
                 |      SUPAHasPolicyClause       |
                 +--------------+-----------------+
                                ^
                                |
                  A             |
                 +--------------+------------+
                 | SUPAHasPolicyClauseDetail |
                 +--------------+------------+
                               / \
                                I
                                I
               +----------------+-----------------------+
               I                I                       I
       C       I         C      I              C        I
      +--------+-----+  +-------+----------+  +---------+-----+
      |Event subclass|  |Condition subclass|  |Action subclass|
      +--------------+  +------------------+  +---------------+

          Figure 8.  Instantiating a SUPAECAPolicyRule, part 2

4.4.3.  Creating SUPA Policy Clauses

   There are two different types of Policy Components. They are a
   SUPAPolicyClause and building a SUPAPolicyComponentDecorator. The former policy model is used to construct SUPAECAPolicyRules, while the latter is used
   to add behavior tendency to
   have a SUPAPolicyClause. This enables the structure
   and capabilities multitude of the SUPAPolicyClause classes, and hence object instances, to be adjusted
   dynamically at runtime.

   However, since each SUPAECAPolicyRule can be made up
   represent different combinations of policy events, conditions, and
   actions. This can lead to class and/or relationship explosion.
   Please see Appendix A for a variable
   number of SUPAPolicyComponents, the decorator pattern is used comparison to
   "wrap" any concrete subclass of SUPAPolicyClause with zero or more
   concrete subclasses of previous work.

   SUPAPolicyClauses are constructed using the PolicyComponentDecorator object. Decorator Pattern
   [11]. This
   avoids problems of earlier models that resulted in is a proliferation
   of classes and relationships.

   Figure 9 shows these two class subclasses. Note that the decorator design pattern [11] is used to enable subclasses of the
   SUPAPolicyComponentDecorator class to add their attributes and/or that enables behavior to a SUPAPolicyClause (as stated in section 4.3) be
   selectively added to an individual object, either statically or
   dynamically, without affecting the behavior of other objects from
   the same class. More
   specifically, concrete subclasses The decorator pattern uses composition, instead of the (abstract)
   SUPAPolicyComponentDecorator
   inheritance, to avoid class can be used and relationship explosion. The
   decorator pattern also enable new objects to decorate, be composed from
   parts or
   "wrap", any all of existing objects without affecting the concrete subclasses of existing
   objects.

   This enables the (abstract) resulting SUPAPolicyClause class.

              A
             +------------------------------+ 1..n
             | SUPAPolicyComponentStructure +----------------------+
             +----------------+-------------+                      |
                             / \                                   |
                              I  SUPAHasPolicyComponentDecorators  |
                              I                                    |
               +--------------+-----------+                        |
               I                          I                        |
      A        I             A            I                        |
     +---------+--------+  +--------------+---------------+ 0..1   |
     |                  |  |                              |/ \     |
     | SUPAPolicyClause |  | SUPAPolicyComponentDecorator + A -----+
     |                  |  |                              |\ /
     +------------------+  +------------------------------+

         Figure 9.  Subclasses of SUPAPolicyComponentStructure

   Instead of using inheritance to statically create new classes to
   represent new types of objects, the decorator pattern uses
   composition to dynamically combine attributes and behavior be constructed
   completely from
   existing objects into new objects. This is done by defining an
   interface in SUPAPolicyComponent that all of the subclasses of
   SUPAPolicyComponent conform to. Since SUPA information model. This
   facilitates the subclasses are construction of the
   same type as SUPAPolicyComponent, they all have the same interface. policies at runtime by a machine.
   This allows each concrete SUPAPolicyComponentDecorator subclass to
   add its attributes and/or behavior to the concrete subclass is also true of
   SUPAPolicyClause that it [2] and [5]; however, this is decorating (or "wrapping").

   This represents an important design optimization for data NOT true of
   most other models.
   Note that Please see Appendix A for a single SUPAECAPolicyRule comparison to
   previous work.

   SUPAPolicyClauseComponentDecorator is the superclass for 4 classes
   in the GPIM, and one additional class in the EPRIM, that can consist of any number of
   SUPAPolicyClauses, each of very different types. If inheritance
   was used, then be used
   to form a subclass AND an aggregation would SUPAPolicyClause. Each of these five classes may be required for
   each separate used
   with all other classes, if desired. These classes are:

      o SUPAPolicyTerm, which enables a clause that makes up the policy rule.

   Clearly, continuing to create subclasses is not practical. Worse,
   suppose composite objects are desired (e.g., be defined in a new
        canonical {variable, operator, value} form
      o SUPAGenericDecoratedComponent, which enabled a custom object Foo is
   made up
        to be defined and then used in a SUPAPolicyClause
      o SUPAPolicyCollection, which enables a collection of existing objects Bar
        to be gathered together and Baz). If associated with all that was needed
   was one attribute of Bar and two or a portion
        of Baz, the developer would still
   have a SUPAPolicyClause
      o SUPAPolicyComponentDecorator, which enables additional
        Decorators to use wrap the entire Bar SUPAPolicyClauseComponentDecorator
      o SUPAECAComponent, which defines Events, Conditions, and Baz classes.
        Actions as reusable objects

   This is wasteful and
   inefficient. In contrast, the decorator pattern enables all, or
   just some, of approach facilitates the attributes and/or behavior machine-driven construction of a class to "wrap"
   another class. This
   policies. Note that this is used heavily in many production systems
   (e.g., the java.io package) because the result completely optional; policies do not
   have to use these constructs.

4.3.6.  SUPAPolicyTarget

   A SUPAPolicyTarget is only the
   behavior a set of managed entities that a SUPAPolicy
   is required, applied to. A set includes individual and no other objects group membership.
   Data models implementations are affected.

   The SUPAPolicyComponentDecorator class hierarchy is used free to define
   objects populate the set using any
   appropriate mechanisms, such as reference by a property such as one
   or more roles, explicit lists, predicate expressions, or others.

   Note that may be used the decision to construct define a SUPAPolicyClause. The
   decorator object can add behavior before, and/or after, it
   delegates to managed entity as a
   SUPAPolicyTarget belongs with the object management system; this
   model simply represents the fact that it a given managed entity is decorating. The subclasses of
   SUPAPolicyComponentDecorator provide
   defined as a very flexible and completely
   dynamic mechanism to:

     1) add or remove behavior to/from an object
     2) SUPAPolicyTarget. Furthermore, the policy-based
   management system SHOULD ensure that objects are constructed using the minimum amount
        of features and functionality required

   SUPAPolicyComponentDecorator defines four subclasses, as shown in
   Figure 10.
                          A
                        +------------------------------+
                        | SUPAPolicyComponentDecorator |
                        +--------------+---------------+
                                      / \
                                       I
                                       I
                                       I
            +------------+-------------+----------------+
            I            I             I                I
    A       I            I    C        I                I
   +--------+-------+    I   +---------+------------+   I
   | SUPAPolicyTerm |    I   | SUPAPolicyCollection |   I
   +----------------+    I   +----------------------+   I
     (for defining       I  (for defining sets and/or   I
      clauses in a       I      groups of objects)      I
    canonical form)      I                              I
                         I                              I
         C               I                     A        I
        +----------------+--------------+     +---------+--------+
        | SUPAGenericDecoratedComponent |     | SUPAECAComponent |
        +-------------------------------+     +------------------+
            (for decorating concrete         (for defining reusable
         subclasses of SUPAPolicyClause)      event, condition,
                                              and action objects)

         Figure 10.  Subclasses of SUPAPolicyComponentDecorator

   If a SUPAEncodedClause is being used, then there is no need to
   use any of management entity
   performing the SUPAPolicyComponentDecorator subclasses, since management operations has the SUPAEncodedClause already completely defines proper permissions to
   perform the content requested management operations. The design of the SUPAPolicyClause.

   However, if a SUPAEncodedClause
   SUPAPolicyTarget addresses both of these criteria.

4.3.7.  SUPAPolicySource

   A SUPAPolicySource is NOT being used, then a
   SUPAPolicyClause will be constructed using one or more types set of
   objects managed entities that authored, or
   are each subclasses of SUPAPolicyComponentDecorator.

   These four subclasses provide four different ways to construct a
   SUPAPolicyClause:

     1) SUPAPolicyTerm: as otherwise responsible for, this SUPAPolicy. Note that a {variable, operator, value} clause
     2) SUPAEncodedClause: as an encoded object (e.g., to pass YANG
   SUPAPolicySource does NOT evaluate or CLI code)
     3) SUPAPolicyCollection: execute SUPAPolicies. Its
   primary use is for auditability and the implementation of deontic
   and/or alethic logic.

4.4.  The Design of the GPIM

   The GPIM defines a policy as a collection type of objects that
        requires further processing in order to PolicyContainer. For this
   version, only ECA Policy Rules will be made into a
        SUPAPolicyClause
     4) SUPAECAComponent: subclasses define reusable Event,
        Condition, or Action objects

   These four different types of objects can described. However, it
   should be intermixed. For
   example, noted that the first and last mechanism described is applicable to
   other types can be combined of policies (e.g., declarative) as follows:

     Variable == Event.baz                                        (A)
     Condition BETWEEN VALUE1 and VALUE2                          (B)
     (Event.severity == 'Critical' AND
       (SLA.violation == TRUE OR User.class == 'Gold'))           (C)

   In well.

4.4.1.  Structure of Policies

   Recall that a PolicyContainer was defined as a special type of
   container that provides at least the above rules, (A) following three functions:

      1.  It uses Event.baz to refer metadata to an attribute
   of define how its content is described
          and/or prescribed
      2.  It separates the Event class; (B) defines two different instances content of a Value
   class, denoted as Value1 and Value2; (C) uses the nomenclature
   foo.bar, where foo is policy from the name
          representation of the policy
      3.  It provides a class, and bar convenient control point for OAMP operations.

   The first requirement is provided by the name ability for any subclass
   of
   an attribute Policy (the root of that class.

4.4.4.  Creating SUPAPolicyClauses

   The GPIM defines a single subclass the information model) to aggregate one or
   more concrete instances of SUPAPolicyClause, called
   SUPAEncodedClause. a SUPAPolicyMetadata class. This clause is generic
   explained in nature, and MAY be
   used with any type of policy (ECA or otherwise). detail in section 5.2.2.

   The EPRIM
   defines an ECA-specific subclass of the GPIM, called a
   SUPABooleanClause, which second requirement is intended to be used with just met by representing an ECA policy rules; however, other uses are also possible.

   Together, Policy as
   having two parts: (1) a rule part and (2) components that make up
   the GPIM rule. Since functional and EPRIM provide several alternatives to
   implement a SUPAPolicyClause, enabling declarative policies are not,
   strictly speaking, "rules", the developer to
   optimize former is named PolicyStructure,
   while the solution for different constraints:

     1) latter is named PolicyComponentStructure.

   The SUPAPolicyClause can be encoded using one or more
        SUPAEncodedClauses; a SUPAEncodedClause encodes third requirement is met by the
        entire content concrete subclasses of its respective event, condition, or
        action clause.
     2) The SUPAPolicyClause can be defined using one or more
        SUPABooleanClauses; each
   PolicyStructure. Since they are PolicyContainers, they are made
   up of the three clauses can be
        defined as either a single SUPABooleanClause, or a
        combination of SUPABooleanClauses SUPAECAPolicyRule, its commponents, and any metadata
   that are logically
        ANDed, ORed, and/or NOTed.
     3) The above two mechanisms can be combined (e.g., the first
        used applies to define the event clause, and the second used to
        define PolicyContainer, the condition and action clauses).

   Figure 11 shows SUPAECAPolicyRule, and.or
   any components of the subclasses SUPAECAPolicyRule. This provides optional
   low-level control over any part of SUPAPolicyClause. the SUPAECAPolicyRule.

   The above requirements result in the design shown in Figure 7.

  A
                         +------------------+                     SUPAHasPolicyMetadata   A
 +------------------+/ \                      \+--------------------+
 | SUPAPolicyClause SUPAPolicyObject + A -----------------------+ SUPAPolicyMetadata |
                         +--------+---------+
 +---------+--------+\ /                      /+--------------------+
          / \        0..n                  0..n
           I
           I
                                  I
                  +---------------+-------------+
           +------+------------------------------------+
                  I                                    I
          A       I                 C                  A                 I
         +--------+----------+       +----------+--------+
         +--------+------------+    +------------------+-----------+
         | SUPABooleanClause SUPAPolicyStructure |    | SUPAEncodedClause SUPAPolicyComponentStructure |
         +-------------------+       +-------------------+
         +--------+------------+    +-------------+----------------+
                 / \                             / \
                  I                               I
                  I                               I
          (subclasses representing        (subclasses representing
        different types of policies)    different policy components)

                      Figure 11.  Subclasses 7.  Structure of SUPAPolicyClause

   SUPABooleanClause is defined a Policy

   Note that aggregation in the EPRIM, and Figure 7 (named SUPAHasPolicyMetadata)
   is used realized as an association class, in order to
   construct Boolean clauses that collectively make up a
   SUPAPolicyClause. It is abstract, so that the composite pattern manage which set
   of Metadata can be applied to it, aggregated by which enables hierarchies SUPAPolicyObject. The
   combination of Boolean
   clauses to be created. SUPAEncodedClause (see section 6.7) is
   used these three functions enables a PolicyContainer
   to encode define the content of a SUPAPolicyClause as an attribute
   (instead behavior of reusable objects).

4.4.5.  SUPAPolicySources

   A SUPAPolicySource how its constituent components will be
   accessed, queried, stored, retrieved, and how they operate.

   It is a set often necessary to construct groups of managed entities that authored,
   or are otherwise responsible for, this SUPAPolicy. Note that a
   SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its
   primary use is for auditability, authorization policies, policies. The GPIM
   follows [2] and
   other applications of deontic and/or alethic logic.

   SUPAPolicyStructure defines four relationships. Two of these
   (SUPAHasPolicySource [5], and SUPAHasPolicyTarget), which are both
   aggregations, relate a SUPAPolicyStructure uses the composite pattern [11] to
   implement this functionality, as shown in Figure 8 below. There
   are a SUPAPolicySource
   and a SUPAPolicyTarget, respectively. Since SUPAECAPolicyRule is
   a subclass of SUPAPolicyStructure, it (and its subclasses) inherit
   both number of these aggregations. This enables SUPAPolicySources and/or
   SUPAPolicyTargets to be attached to SUPAECAPolicyRules (but NOT advantages to
   components of using the composite pattern over a SUPAPolicy).
   simple relationship, as detailed in [11].

   Figure 12 8 shows how SUPAPolicySources and SUPAPolicyTargets are
   attached to that SUPAPolicyStructure has a SUPAPolicy. Note single subclass,
   called SUPAECAPolicyRule. Note, however, that both other types of these aggregations
   are defined as optional, since their multiplicity
   policies, such as declarative policies, can be defined as
   subclasses of SUPAPolicyStructure in the future.

                               A
                              +---------------------+
                              | SUPAPolicyStructure |
                              +--------+------------+
                                      / \
                                       I
                                       I
                       +---------------+----------------+
                       I                                I
            C          I                     A          I
      +----------------+---------------+    +-----------+-----------+
      | Future Subclasses to Represent |    |   SUPAECAPolicyRule   |
      |  Represent Different Policies  |    +-----------------------+
      +--------------------------------+

    Figure 8.  The Composite Pattern Applied to SUPAPolicyStructure

4.4.2.  Representing an ECA Policy Rule

   An ECA policy rule is 0..n - 0..n.
   In addition, both a 3-tuple, which is made up of an event
   clause, a condition clause, and an action clause. Each of these aggregations
   three types of clauses may in turn be made up of a Boolean
   combination of clauses of that type. Each clause may be viewed as
   a predicate, as it provides a TRUE or FALSE output. The canonical
   form of a clause is a 3-tuple of the form "variable operator value",
   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
   using the operators OR and NOT.

   A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract
   subclass of SUPAPolicyStructure.

   Note that the aggregation SUPAHasPolicyClause in Figure 9 is
   realized as an association classes, class, in order to manage which set
   of SUPAPolicyClauses can be able to control aggregated by which
   SUPAPolicySources set of
   SUPAECAPolicyRules. This aggregation is defined at the
   SUPAPolicyStructure level, and SUPAPolicyTargets are attached to a given
   SUPAECAPolicyRule. not at the lower level of
   SUPAECAPolicyRule, so that non-ECA policies can also use this
   aggregation.

     A                                   A
    +---------------------------+       +------------------+
    | SUPAPolicyObject    SUPAPolicyStructure    |
                     +--------+---------+       | SUPAPolicyClause |
    +---------+---------+-------+       +----------+-------+
             / \       / \ 0..1              1..n / \
              I         A                          |
              I        \ /                         |
              I
               +--------------+-----+---------------------+
               I         |                          |
              I         |   SUPAHasPolicyClause    |
              I         +---------------+----------+
      A       I             C                         I             C
     +--------+----------+      A       I
   +-----------+---------+  +-------+--------+   +--------+-------+
     | SUPAPolicyStructure SUPAECAPolicyRule |  |SUPAPolicySource|   |SUPAPolicyTarget|
   +------+-------+------+  +----------+-----+   +----------+-----+
    0..n     +--------+------------------+
     +-------------------+     | SUPAHasPolicyClauseDetail |
                               +---------------------------+

      Figure 9.  SUPAECAPolicyRule Aggregating SUPAPolicyClauses

   Since a SUPAECAPolicyRule consists of three SUPAPolicyClauses,
   at least three separate instances of the SUPAHasPolicyClause
   aggregation are instantiated in order to make a complete
   SUPAECAPolicyRule, as shown in Figure 10.

       A                                   A
      +-------------------+               +--------------------+
      | SUPAECAPolicyRule |               |  SUPAPolicyClause  |
      +--+----+----+------+               +-------+----+----+--+
        / \  / \ 0..n        0..n  / \             0..n  0..1               1..n   / \  / \  / \
         A    A    A                              |    |    |
        \ /  \ /  \ /                             |    |    |
         |    |    |                              |    |    |
         |    |       +--------------------+    |  SUPAHasPolicyClause #1      |         SUPAHasPolicySource    |    |
         |
          +-------------------------------------------------+
                           SUPAHasPolicyTarget    |    +------------------------------+    |    |
         |    |                                        |    |
         |    |         SUPAHasPolicyClause #2         |    |
         |    +----------------------------------------+    |
         |                                                  |
         |                SUPAHasPolicyClause #3            |
         +--------------------------------------------------+

     note: all 3 aggregations have a multiplicity of 0..1 - 1..n

         Figure 12.  ECAPolicyRules, SUPAPolicySources, and PolicyTargets

   A SUPAPolicySource MAY be mapped to 10.  Instantiating a role (e.g., using the
   role-object pattern [11]); this indirection makes the system less
   fragile, SUPAECAPolicyRule, part 1

   In figure 10, SUPAECAPolicyRule is shown as entities can be transparently added or removed "owning" these three
   aggregations, since it inherits them from its superclass
   (SUPAPolicyStructure). The three aggregations represent the role definition without adversely affecting the definition
   event, condition, and action clauses of
   the SUPAPolicy. a SUPAECAPolicyRule.
   Note that SUPAPolicyRole is a subclass each of
   SUPAPolicyMetadata.

4.4.6.  SUPAPolicyTargets

   A SUPAPolicyTarget defines the set these clauses MAY consist of managed entities that a
   SUPAPolicy is applied to. This is useful for debugging, as well as
   when the nature one or more
   SUPAPolicyClauses. Similarly, each SUPAPolicyClause MAY consist
   of the application requires the set one or more predicates. In this way, complex event, condition,
   and action clauses, which are combinations of managed
   entities affected by Boolean expressions
   that form a Policy logical predicate) are supported, without having to be explicitly identified. This
   define additonal objects (as is
   determined by two conditions:

     1) done in previous work; please
   see Appendix A for a comparison to previous work.

   The set multiplicity of managed entities that are to be affected by the
        SUPAPolicy must all agree to play SUPAHasPolicyClause aggregation is
   0..n on the role of a
        SUPAPolicyTarget. For example, a managed entity may not be
        in a state aggregate side and 1..n on the part side. This means
   that enables SUPAPolicies to be applied to it;
        hence, in this case, it a particular SUPAECAPolicyRule MUST NOT assume the role of aggregate at least one
   SUPAPolicyClause, and that a
        SUPAPolicyTarget
     2) A SUPAPolicyTarget must given SUPAPolicyClause MAY be able to:
        a) process (either directly or with the aid of a proxy)
           SUPAPolicies,
   aggregated by zero or
        b) receive the results of a processed SUPAPolicy and
           apply those results to itself.

   Figure 12 showed how SUPAPolicyTargets are attached to
   SUPAECAPolicyRules.

   A SUPAPolicyTarget more SUPAECAPolicyRule objects.

   This cardinality MAY be mapped refined to 3..n for SUPAECAPolicyRules,
   since a role (e.g., using SUPAECAPolicyRule MUST have at least three separate clauses.
   However, since a SUPAPolicyStructure is the
   role-object pattern [11]); owner of this indirection makes
   aggregation (which is inherited by SUPAECAPolicyRule), the system less
   fragile, as entities can
   cardinality is defined to be transparently added or removed from
   the role definition without adversely affecting 1..n on the definition part side because other
   types of
   the SUPAPolicy. Note Policies have different needs. The 0..n cardinality
   means that SUPAPolicyRole is a subclass of
   SUPAPolicyMetadata.

4.4.7.  Policy Metadata

   Metadata is, literally, data about data. As such, it can SUPAPolicyClause may be
   descriptive aggregated by zero or prescriptive in nature.

4.4.7.1.  Motivation

   There more
   SUPAECAPolicyRules. The zero is a tendency in class design to make certain attributes,
   such as description, status, validFor, and provided so forth, bound to that SUPAPolicyClauses
   can be stored in (for example) a
   specific class (e.g., [6]). This repository before the
   SUPAECAPolicyRule is bad practice in an information
   model. For example, different classes in different parts of created; the
   class hierarchy "or more" recognizes the fact
   that multiple SUPAECAPolicyRules could require aggregate the use of any same
   SUPAPolicyClause.

   In Figure 10, suppose that SUPAHasPolicyClause#1, #2, and #3
   represent the aggregations for the event, condition, and action
   clauses, respectively. This means that each of these attributes;
   if one class is not a subclass of the other, then they
   SUPAHasPolicyClause aggregations must each
   define explicitly identify the same attribute as part
   type of their class structure. This
   makes clause that it difficult to find all instances represents.

   In looking at Figure 10, there is no difference between any of the attribute and
   ensure that they are synchronized. Furthermore, context can
   dynamically change the status of an object, so an easy way to
   update
   three aggregations, except for the status of one object instance without affecting other
   instances type of clause that the same object
   aggregation represents (i.e., event, condition, or action clause).

   Therefore, three different aggregations, each with their own
   association class, is required.

   Many models, not needed. Instead, the GPIM defines a
   single aggregation (SUPAHasPolicyClause) that is realized using a
   (single) abstract association class (SUPAHasPolicyClauseDetail);
   this association class is then subclassed into three concrete
   subclasses, one each to represent the semantics for an event,
   condition, and action clause.

   The policy management system may use any number of different
   software mechanisms, such as [4] and [6], take a simplistic approach introspection or reflection, to
   determine the nature of
   defining a common attribute high the aggregation (i.e., what object types
   are being aggregated) in order to select the hierarchy, appropriate subclass
   of SUPAHasPolicyClauseDetail. The three subclasses of
   SUPAHasPolicyClauseDetail are named SUPAHasPolicyEventDetail,
   SUPAHasPolicyConditionDetail, and making it
   optional. This violates classification theory, SUPAHasPolicyActionDetail,
   respectively. While Event, Condition, and defeats Action objects are
   typically used in ECA policy rules, the
   purpose design in this document
   enables them to be used as policy components of an information model, which other types of
   policies as well. This is to specify the
   differences shown in characteristics and behavior between classes (as
   well as define how Figure 11.

        A                               A
       +-------------------+           +------------------+
       | SUPAECAPolicyRule |           | SUPAPolicyClause |
       +---------+---------+           +----------+-------+
                / \ 1..n                    0..n / \
                 A                                |
                \ /                               |
                 |                                |
                 |      SUPAHasPolicyClause       |
                 +--------------+-----------------+
                                ^
                                |
                  A             |
                 +--------------+------------+
                 | SUPAHasPolicyClauseDetail |
                 +--------------+------------+
                               / \
                                I
                                I
               +----------------+-----------------------+
               I                I                       I
       C       I         C      I              C        I
      +--------+-----+  +-------+----------+  +---------+-----+
      |Event subclass|  |Condition subclass|  |Action subclass|
      +--------------+  +------------------+  +---------------+

          Figure 11.  Instantiating a SUPAECAPolicyRule, part 2

4.4.3.  Creating SUPA Policy Clauses

   There are two different classes types of Policy Components. They are related to each other).
   Note that this also violates a number of well-known software
   architecture principles, including:

      o
   SUPAPolicyClause and a SUPAPolicyClauseComponentDecorator. The
   former is used to construct SUPAECAPolicyRules, while the Liskov Substitution Principle [13]
        (if A latter
   is used to add behavior to a subclass of B, then objects instantiated from
        class B may be replaced with objects instantiated from
        class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS)
      o SUPAPolicyClause. This enables the Single Responsibility Principle [14]
        (every class should have responsibility over one,
   structure and only
        one, part capabilities 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 SUPAPolicyClause 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
   simpler, but has some well-known problems. One be adjusted
   dynamically at runtime. This is called "weak
   encapsulaton", meaning that a subclass shown in Figure 12.

             A
            +------------------------------+
            | SUPAPolicyComponentStructure |
            +---------------+--------------+
                           / \
                            I
                            I
            +---------------+--------------------+
            |                                    |
    A       |                     A              |
   +--------+---------+          +---------------+--------------------+
   |                  |          |                                    |
   | SUPAPolicyClause |          | SUPAPolicyClauseComponentDecorator |
   |                  |          |                                    |
   +------------------+          +---------------------------+--------+
         / \ 0..n                                      0..n / \
          A                                                  |
         \ /                                                 |
          |                                                  |
          |           SUPAPolicyClauseHasDecorator           |
          +--------------------------------------------------+

                 Figure 12.  Decorating SUPAPolicyClauses

   Every SUPAPolicyClause can use attributes and
   methods be made up of a superclass, but if variable number of
   SUPAPolicyClauseComponentDecorators, so the superclass changes, multiplicity of the
   subclass may break. Another
   SUPAPolicyClauseHasDecorator aggregation is 0..n - 0..n. This means
   that each time a new object is
   required, a new subclass must be created. These problems are
   present in [RFC3460], [4], SUPAPolicyClause may have zero or more decorating objects,
   and [6].

   Composition is an alternative that provides code a SUPAPolicyClauseComponentDecorator MAY be associated with
   zero or more SUPAPolicyClauses. Note that is easier the "zero" part of this
   multiplicity enables SUPAPolicyClauseComponentDecorator objects to
   use. This means that composition can provide data models that are
   more resistant
   be stored in a PolicyRepository without having to change and easier be bound to use. By using composition,
   we can select just ability
   particular SUPAPolicyClause. The use of the metadata objects that are needed, instead decorator pattern avoids
   problems encountered in earlier models, which resulted in a
   proliferation of having classes and relationships.

   Instead of using inheritance to rely on statically defined objects. We can even create new objects from a set classes to
   represent new types of existing objects through
   composition. Finally, we can use objects, the decorator pattern uses
   composition to select
   just the dynamically combine attributes and behaviors behavior from
   existing objects into new objects. This is done by defining an
   interface in SUPAPolicyComponent that all of the subclasses of
   SUPAPolicyComponent conform to. Since the subclasses are required for a given
   instance.

   In [2] and [5], a separate metadata class hierarchy is defined to
   address this problem. This document follows this approach.

4.4.7.2.  Design Approach

   The goal of the GPIM is to enable metadata
   same type as SUPAPolicyComponent, they all have the same interface.
   This allows each concrete SUPAPolicyClauseComponentDecorator
   subclass to be attached add its attributes and/or behavior to any the concrete
   subclass of SUPAPolicyObject SUPAPolicyClause that requires it. Since this is a
   system intended for policy-based management, it therefore makes
   sense to be able to control which metadata is attached to which
   policies dynamically (i.e., at runtime).

   One solution is to use the Policy Pattern [1], [2], [6], [12]. decorating (or "wrapping").

   This pattern was built to work with management systems whose
   actions were dependent upon context. The Policy Pattern works as
   follows:

      o Context is derived from all applicable system inputs (e.g.,
        OAMP represents an important design optimization for data from network elements, business goals, time of
        day, geo-location, etc.).
      o Context is then used to select models.
   Note that a working set of Policies.
      o Policies are then used to define behavior at various
        control points in the system.
      o One simple type single SUPAECAPolicyRule can consist of control point is an association class.
        Since the association class represents the semantics any number of how
        two classes are related to
   SUPAPolicyClauses, each other, of very different types. If inheritance
   was used, then
         o ECAPolicyRule actions can a subclass AND an aggregation would be used to change required for
   each separate clause that makes up the attribute
           values, methods, policy rule.

   Suppose composite objects are desired (e.g., a new object Foo is
   made up of existing objects Bar and relationships Baz). If all that was needed
   was one attribute of the association
           class
         o This has the affect Bar and two of changing how Baz, the two classes are
           related developer would still
   have to each other
      o Finally, as context changes, use the working set entire Bar and Baz classes. This is wasteful and
   inefficient. In contrast, the decorator pattern enables all, or
   just some, of policies
        change, enabling the attributes and/or behavior of a class to be adjusted to follow
        changes in context (according to appropriate business goals "wrap"
   another class. This is used heavily in many production systems
   (e.g., the java.io package) because the result is only the
   behavior that is required, and no other factors, of course) in a closed loop manner.

   Conceptually, this objects are affected.

   SUPAPolicyClauseComponentDecorator is accomplished the superclass of five
   subclasses, as shown in Figure 13 below.

                      Defines
     +----------+     Behavior                  +------------+
     | Policies +----------------+              | SUPAPolicy |
     +----+-----+ 1..n           |              +------+-----+
    0..n / \                     |                    / \ 0..n
          |                      | 13.

                      A
                     +------------------------------------+
                     | SUPAPolicyClauseComponentDecorator |                    \
                     +-----------------+------------------+
                                      /
          |                1..n \ /                    |
          |          +-----------+--------------+      |
          |          | SUPAPolicyMetadataDetail |      |
          |          +-----------+--------------+      |
          |                      |                     |
          | Selects              |                     |
          | Policies             |
                                       I
                                       I
                                       I
            +------------+-+-----------+------------------+
            I            I I             I                I
    A       I            I I    C        I                I
   +--------+-------+    I I   +---------+------------+   I
   | SUPAPolicyTerm |    I I   | SUPAPolicyCollection |   I
   +----------------+    I I   +----------------------+   I
     (for defining       I I   (for defining sets and/or  I
      clauses in a       I I    groups of objects)        I
    canonical form)      I I                              I
                         I +---------------+              I
         C               I                 I     A        I
        +----------------+--------------+  I    +---------+--------+
        |                      +-------------------->+ SUPAGenericDecoratedComponent |                             Applies  I    |
         / \                            Behavior SUPAECAComponent |
        +-------------------------------+  I    +------------------+
            (for decorating concrete       I   (for defining reusable
         subclasses of SUPAPolicyClause)   I    event, condition,
                                           I    and action objects)
                                           I
                               A           I
                             +-------------+----------------+
                             |
    0..n \ /                                          \ / 0..n
     +----+-----+                             +--------+---------+
     | Context SUPAPolicyComponentDecorator |                             |SUPAPolicyMetadata|
     +----------+                             +------------------+
                             +------------------------------+
                   (for decorating SUPAPolicyClauseComponentDecorator
                     objects with SUPAPolicyComponentDecorator objects)

     Figure 13.  Context-Aware Policy Rules

4.4.7.2.1.  Policies and Actors

   The Policy Continuum ([1] [5] [10] [12]) was defined to associate
   different actors with different policies at different levels  Subclasses of
   business and/or technical specificity. Context-aware policy rules,
   and the Policy Pattern, were defined SUPAPolicyClauseComponentDecorator

   The SUPAPolicyClauseComponentDecorator class hierarchy is used to realize this association.

   Four important functions related
   define classes that may be used to the lifecycle of policies are
   design, implementation, deployment, and execution. There are many
   different possible definitions of these functions (even for policy
   lifecycle management); however, for the purposes of this document,
   they are defined as follows:

      o Design:       The process of defining construct a software architecture SUPAPolicyClause. The
   decorator object can add behavior before, and/or after, it
   delegates to satisfy user requirements.
      o Development: the process of documenting, programming,
                      testing, and maintaining code and applications
                      as part object that it is decorating. The subclasses of
   SUPAPolicyClauseComponentDecorator provide a software product
      o Deployment:   the process that assembles very flexible and transfers
                      completed software artifacts to
   completely dynamic mechanism to:

     1) add or remove behavior to/from a state SUPAPolicyClause object
     2) ensure that
                      enables their execution
      o Execution: objects are constructed using the process minimum amount
        of installing, activating, running, features and subsequently deactivating executable
                      software products

   The design process is responsible for producing functionality required

   If a software
   architecture. This emphasizes the design, as opposed SUPAEncodedClause is being used, then there is no need to the
   programming,
   use any of software systems. In contrast to design,
   development emphasizes constructing software artifacts via coding
   and documentation.

   Deployment may be described as the process of releasing software.
   It includes all of SUPAPolicyClauseComponentDecorator subclasses, since
   the operations required to assemble a completed
   software product. It typically also includes SUPAEncodedClause already completely defines the process content of
   preparing a software product for execution (e.g., assembling
   the SUPAPolicyClause.

   However, if a set
   of software products into SUPAEncodedClause is NOT being used, then a larger product, determining if the
   consumer site has appropriate resources
   SUPAPolicyClause SHOULD be constructed using one or more types of
   concrete subclasses of SUPAPolicyClauseComponentDecorator.

   These five subclasses provide five different ways to install and execute construct a
   SUPAPolicyClause:

     1) SUPAPolicyTerm: as a {variable, operator, value} clause
     2) SUPAGenericDecoratedComponent: as an encoded object (e.g., to
         pass YANG or CLI code)
     3) SUPAPolicyCollection: as a collection of objects that
        requires further processing in order to be made into a
        SUPAPolicyClause
     4) SUPAECAComponent: subclasses define reusable Event,
        Condition, or Action objects
     5) SUPAPolicyComponentDecorator: as a new type of Decorator to
        augment any of the
   software product, above four mechanisms

   These four different types of objects can be intermixed. For
   example, the first and collecting information on fourth types can be combined as follows:

     Variable == Event.baz                                        (A)
     Condition BETWEEN VALUE1 and VALUE2                          (B)
     (Event.severity == 'Critical' AND
       (SLA.violation == TRUE OR User.class == 'Gold'))           (C)

   In the feasibility above rules, (A) uses Event.baz to refer to an attribute
   of
   using the software product). This contrasts with Event class; (B) defines two different instances of a Value
   class, denoted as Value1 and Value2; (C) uses the execution
   process, which nomenclature
   foo.bar, where foo is the set name of processes that follow deployment.

   In summary, exemplar states in the policy lifecycle process
   include:

      o Design:       determining how the policy-based management
                      system will operate
      o Development:  documenting, programming, testing, and
                      maintaining policies a class, and policy components
      o Deployment:   assembling bar is the components name of
   an attribute of that class.

4.4.4.  Creating SUPAPolicyClauses

   The GPIM defines a policy-based
                      management system
      o Execution:    installing, enabling, running, disabling,
                      and uninstalling policies single subclass of SUPAPolicyClause, called
   SUPAEncodedClause. This clause is generic in nature, and policy components

4.4.7.2.2.  Deployment vs. Execution MAY be
   used with any type of Policies

   One policy (ECA or otherwise). The EPRIM
   defines an ECA-specific subclass of the primary reasons for separating the deployment and
   execution processes GPIM, called a
   SUPABooleanClause, which is intended to differentiate between environments that be used with just
   ECA policy rules; however, other uses are not ready to execute policies (i.e., deployment) also possible.

   Together, the GPIM and
   environments that are ready EPRIM provide several alternatives to execute policies (i.e., execution).
   This is an important consideration, since policies that are
   related
   implement a SUPAPolicyClause, enabling the developer to
   optimize the same set of tasks may be deployed in many solution for different
   places (e.g., in a policy system vs. in constraints:

     1) The SUPAPolicyClause can be encoded using one or more
        SUPAEncodedClauses; a network device). In
   addition, each managed entity in SUPAEncodedClause encodes the set
        entire content of SUPAPolicyTargets may its respective event, condition, or may not
        action clause.
     2) The SUPAPolicyClause can be in defined using one or more
        SUPABooleanClauses; each of the three clauses can be
        defined as either a state single SUPABooleanClause, or a
        combination of SUPABooleanClauses that allows SUPAPolicies to are logically
        ANDed, ORed, and/or NOTed.
     3) The above two mechanisms can be applied combined (e.g., the first
        used to
   it (see section 4.4.6.).

   Hence, this design includes dedicated class attributes for
   getting and setting define the deployment and execution status, as well
   as enabling event clause, and disabling, SUPAPolicies (see section 5.3.1.).

4.4.7.2.3.  Using SUPAMetadata for Policy Deployment the second used to
        define the condition and Execution

   One way action clauses).

   Figure 14 shows the subclasses of encoding deployment and execution status for policies
   and policy components is to attach Metadata objects to affected
   SUPAPolicyStructure and SUPAPolicyComponentStructure objects.
   This provides an extensible and efficient means to describe
   and/or prescribe deployment and/or execution status SUPAPolicyClause.

                          A
                         +------------------+
                         | SUPAPolicyClause |
                         +--------+---------+
                                 / \
                                  I
                                  I
                                  I
                  +---------------+-------------+
                  I                             I
          A       I                   C         I
         +--------+----------+       +----------+--------+
         | SUPABooleanClause |       | SUPAEncodedClause |
         +-------------------+       +-------------------+

            Figure 14.  Subclasses of a policy
   or a policy component. It SUPAPolicyClause

   SUPABooleanClause (see Section 6.7) is extensible, since classes defined in the EPRIM, and
   relationships can be used, as opposed is
   used to construct Boolean clauses that collectively make up a set of attributes.
   SUPAPolicyClause. It is efficient, because abstract, so that the decorator composite pattern (see section 5.7) is
   used (this enables attributes and/or methods of objects, or the
   entire object, to be used to add characteristics and/or behavior
   to a given object.

   SUPAPolicyMetadata objects (see sections 5.16 - 5.20) may
   can be
   attached applied to the SUPAECAPolicyRule and/or any it, which enables hierarchies of its components Boolean
   clauses to define additional semantics of the SUPAECAPolicyRule. For
   example, SUPAAccessMetadataDef (see section 5.19) and/or
   SUPAVersionMetadataDef (see section 5.20) may be attached to
   define the access privileges and version information,
   respectively, of a policy rule and/or its components.

   The SUPAPolicyStructure defines an attribute, supaPolDeployStatus, created. SUPAEncodedClause (see section 5.3.1.3.) that SUPAPolicyMetadata objects can
   use to get and set the deployment and execution status of a
   SUPAPolicy. This allows metadata to be 5.6) is
   used to alter encode the
   deployment and/or execution state content of a policy (or SUPAPolicyClause as an attribute
   (instead of reusable objects).

4.4.5.  SUPAPolicySources

   A SUPAPolicySource is a set of
   policy components) without having to affect other parts of the
   policy-based management system. The supaPolDeployStatus attribute
   indicates managed entities that this SUPAPolicy can authored,
   or cannot be deployed. If it
   cannot be deployed. Similarly, the supaPolExecStatus attribute
   is used to indicate if are otherwise responsible for, this SUPAPolicy. Note that a particular SUPAPolicy has executed, is
   currently executing,
   SUPAPolicySource does NOT evaluate or execute SUPAPolicies. Its
   primary use is ready to execute, for auditability, authorization policies, and whether or not
   other applications of deontic and/or alethic logic.

   The SUPAHasPolicySource aggregation defines the execution set of
   SUPAPolicySource objects that are sources for a given SUPAPolicy had any failures.

   The reverse
   (as defined by a concrete subclass of SUPAPolicyStructure). Since
   SUPAECAPolicyRule is also true a subclass of SUPAPolicyStructure, it (and hence, forms
   its subclasses) inherit this aggregation. This enables a closed-loop system
   controlled by metadata). For example, if the set of deployed
   SUPAPolicies
   SUPAPolicySource objects to be attached to a particular
   SUPAECAPolicyRule object.

   Figure 15 shows how SUPAPolicySources and SUPAPolicyTargets are SUPAECAPolicyRules, then when the actions
   attached to a SUPAPolicy. Note that both of these SUPAECAPolicyRules aggregations
   are executed, the overall context has
   changed (see section 4.4.7.2). The context manager could then
   change attribute values (directly or indirectly) in the
   SUPAPolicyMetadataDetail association class. This class represents
   the behavior of the SUPAHasPolicyMetadata aggregation, which defined as optional, since their multiplicity is
   used 0..n - 0..n.
   In addition, both of these aggregations are realized as
   association classes, in order to define which SUPAPolicyMetadata can be attached able to control which
   SUPAPolicy objet in this particular context. For example, the
   access privileges of
   SUPAPolicySources and SUPAPolicyTargets are attached to a policy and/or policy component could be
   changed dynamically, according given
   SUPAECAPolicyRule.

                      A
                     +------------------+
                     | SUPAPolicyObject |
                     +--------+---------+
                             / \
                              I
                              I
               +--------------+-----+---------------------+
               I                    I                     I
    A          I             C      I             C       I
   +-----------+---------+  +-------+--------+   +--------+-------+
   | SUPAPolicyStructure |  |SUPAPolicySource|   |SUPAPolicyTarget|
   +------+-------+------+  +----------+-----+   +----------+-----+
    0..n / \     / \ 0..n        0..n / \             0..n / \
          A       A                    |                    |
         \ /     \ /                   |                    |
          |       |                    |                    |
          |       |                    |                    |
          |       +--------------------+                    |
          |         SUPAHasPolicySource                     |
          |                                                 |
          +-------------------------------------------------+
                           SUPAHasPolicyTarget

    Figure 15.  ECAPolicyRules, SUPAPolicySources, and PolicyTargets

   A SUPAPolicySource MAY be mapped to changes in context.

   By a role (e.g., using the decorator
   role-object pattern on SUPAPolicyMetadata, any number
   of SUPAPolicyMetadata objects (or their attributes, etc.) [11]); this indirection makes the system less
   fragile, as entities can be
   wrapped around transparently added or removed from
   the role definition without adversely affecting the definition of
   the SUPAPolicy. Note that SUPAPolicyRole is a concrete subclass of
   SUPAPolicyMetadata.

4.4.6.  SUPAPolicyTargets

   A SUPAPolicyTarget defines the set of managed entities that a
   SUPAPolicy is applied to. This is
   shown in Figure 14 below.

4.4.7.3.  Structure useful for debugging, as well as
   when the nature of SUPAPolicyMetadata

   SUPAPolicyMetadata also uses the decorator pattern to provide an
   extensible framework for defining metadata to attach application requires the set of managed
   entities affected by a Policy to SUPAPolicy
   subclasses. Its be explicitly identified. This is
   determined by two principal subclasses are
   SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. conditions:

     1) The
   former is used to define concrete subclasses set of SUPAPolicyMetadata managed entities that are attached at runtime to SUPAPolicy subclasses, while the
   latter is used to define concrete objects that represent reusable
   attributes, methods, and relationships that can be added affected by the
        SUPAPolicy must all agree to
   subclasses play the role of SUPAPolicyConcreteMetadata. a
        SUPAPolicyTarget. For example, concepts like identification, access control, and
   version information are too complex a managed entity may not be
        in a state that enables SUPAPolicies to represent as be applied to it;
        hence, in this case, it MUST NOT assume the role of a single
   attribute,
        SUPAPolicyTarget
     2) A SUPAPolicyTarget must be able to:
        a) process (either directly or even a couple with the aid of attributes - they require a proxy)
           SUPAPolicies, or
        b) receive the
   generic power results of objects to represent their characteristics a processed SUPAPolicy and
   behavior. Furthermore, defining concrete classes
           apply those results to represent
   these concepts in itself.

   Figure 15 showed how SUPAPolicyTargets are attached to
   SUPAECAPolicyRules.

   The SUPAHasPolicyTarget aggregation defines the policy hierarchy is fragile, because:

     1. not all set of
   SUPAPolicyTarget objects that use these concepts need all of the
        information represented by them are targets for (e.g., two subclasses of an
        Identification Object may will be Passport and Certificate, but
        these two objects are rarely used together, and even those
        contexts that use one of these classes may not need all acted
   on) by a given SUPAPolicy (as defined by a concrete subclass of
        the data in that class)
     2. defining
   SUPAPolicyStructure). Since SUPAECAPolicyRule is a class means defining subclass of
   SUPAPolicyStructure, it (and its attributes, methods, and
        relationships at a particular place in the hierarchy; subclasses) inherit this
        means that defining
   aggregation. This enables a relationship between set of SUPAPolicyTarget objects to be
   attached to a class particular SUPAECAPolicyRule object.

   A and
        another class B SHOULD only SUPAPolicyTarget MAY be done if all of mapped to a role (e.g., using the subclasses
        of B can use
   role-object pattern [11]); this indirection makes the attributes, methods, and relationships of A
        (e.g., in system less
   fragile, as entities can be transparently added or removed from
   the above example, defining a relationship between
        an Identification Object and a superclass role definition without adversely affecting the definition of a router class
   the SUPAPolicy. Note that SUPAPolicyRole is not appropriate, since routers do not use Passports)

      A
     +------------------+
     | SUPAPolicyObject |
     +--------+---------+
             / \ 0..n
              A
             \ /
              |                                A
              |                          0..n +--------------------+
              |   SUPAHasPolicyMetadata      \|                    |
              +-------------+-----------------+ SUPAPolicyMetadata |
                            ^                /|                    |
                            |                 +------+------+------+
               C            |                       / \     | 1..n
              +-------------+---------------+        I      |
         1..n |                             |        I      |
   +----------+ SUPAHasPolicyMetadataDetail |        I      |
   |          |                             |        I      |
   |          +-----------------------------+        I      |
   |                                                 I      |
   | (gets/sets values of attributes and/or          I      |
   |  methods a subclass of the SUPAHasPolicyMetadataDetail     I      |
   |  class; this affects which SUPAPolicyMetadata   I      |
   |  objects
   SUPAPolicyMetadata.

4.4.7.  Policy Metadata

   Metadata is, literally, data about data. As such, it can be attached
   descriptive or prescriptive in nature.

4.4.7.1.  Motivation

   There is a tendency in class design to which policies      I      |
   | make certain attributes,
   such as description, status, validFor, and policy components)                         I      |
   |                                                 I      |
   |          C                                      I      |
   |          +----------------------------+         I      |
   |          |                            |         I      |
   +----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+      |
              |                            |         I      |
              +----------------------------+         I      |
                                                     I      |
              A                                      I      |
             +-----------------------------+         I      |
             |                             |         I      |
             | SUPAPolicyMetadataDecorator +IIIIIIIII+      |
             |                             |                |
             +-------+--------------+------+                |
                    / \            / \ 0..1                 |
                     I              A                       |
                     I             \ /                      |
                     I              |                       |
          subclasses for adding     |                       |
          behavior so forth, bound to policies      +-----------------------+
          and policy components      SUPAHasMetadataDecorator

     Figure 14.  SUPAPolicyMetadata Subclasses and Relationships

   Since a
   specific class encapsulates attributes, methods, and behavior,
   defining the Identification Object (e.g., [6]). This is bad practice in an information
   model. For example, different classes in different parts of the above example as
   class hierarchy could require the use of any of these attributes;
   if one class is not a type subclass of SUPAPolicyMetadata object enables the decorator pattern to be
   used other, then they must each
   define the same attribute as part of their class structure. This
   makes it difficult to attach find all or part instances of the attribute and
   ensure that object they are synchronized. Furthermore, context can
   dynamically change the status of an object, so an easy way to
   update the status of one object instance without affecting other objects that
   need it.

   Figure 15 shows a portion
   instances of the SUPAPolicyMetadata hierarchy.

                  A
                 +--------------------+
                 |                    |  SUPAHasMetadataDecorator
                 | SUPAPolicyMetadata +-------------------+
                 |                    | 1..n              |
                 +---------+----------+                   |
                           I                              |
                           I                              |
                           I                              |
             +-------------+-----------------+            |
             |                               |            |
    C        |                               |           / \
   +---------+------------------+            |            A
   | SUPAPolicyConcreteMetadata |    A       |      0..1 \ /
   +----------------------------+   +--------+------------+-------+
                                    | SUPAPolicyMetadataDecorator |
                                    +------------+----------------+
                                                 I
                  +------------------------------+--------+
                  I                                       I
                  I                                       I
   C              I                  C                    I
  +---------------+-------------+   +---------------------+--------+
  | SUPAPolicyAccessMetadataDef |   | SUPAPolicyVersionMetadataDef |
  +-----------------------------+   +------------------------------+

     Figure 15.  SUPAPolicyMetadata Subclasses same object is required.

   Many models, such as [4] and Relationships

   Figure 15 shows [6], take a relevant portion simplistic approach of the SUPAPolicyMetadata
   hierarchy. SUPAPolicyConcreteMetadata is
   defining a concrete class that
   subclasses of common attribute high in the SUPAPolicyMetadataDecorator class can wrap.
   Two such subclasses, SUPAPolicyAccessMetadataDef hierarchy, and
   SUPAPolicyVersionMetadataDef, are shown in Figure 15. making it
   optional. This
   enables access control violates classification theory, and version defeats the
   purpose of an information model, which is to be added
   statically (at design time) or dynamically (at runtime) to
   SUPAPolicyConcreteMetadata; this enables metadata-driven systems
   to adjust specify the
   differences in characteristics and behavior between classes (as
   well as define how different classes are related to each other).
   Note that this also violates a number of well-known software
   architecture principles, including:

      o the management system to changes in
   context, business rules, services given to end-users, and other
   similar factors. This Liskov Substitution Principle [13]
        (if A is discussed more in sections 5.18 - 5.20.

4.5.  Advanced Features

   This section will be completed in the next revision a subclass of this
   document.

4.5.1.  Policy Grouping

   This section will B, then objects instantiated from
        class B may be completed in replaced with objects instantiated from
        class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS)
      o the next revision Single Responsibility Principle [14]
        (every class should have responsibility over one, and only
        one, part of this
   document.

4.5.2.  Policy Rule Nesting

   This section will be completed in the next revision of this
   document.

5.  GPIM Model
   This section defines functionality provided by the classes, attributes, and relationships of program)
      o the GPIM.

5.1.  Overview 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 overall class hierarchy former is shown in Figure 16; section numbers
   are appended after each class.

   (Class of another model that SUPA
   simpler, but has some well-known problems. One is integrating into)
       |
       +---SUPAPolicyObject (5.2)
       |     |
       |     +---SUPAPolicyStructure (5.3)
       |     |
       |     +---SUPAPolicyComponentStructure (5.4)
       |     |     |
       |     |     +---SUPAPolicyClause (5.5)
       |     |     |     |
       |     |     |     +---SUPAEncodedClause (5.6)
       |     |     |
       |     |     +---SUPAPolicyComponentDecorator (5.7)
       |     |           |
       |     |           +---SUPAPolicyTerm (5.8)
       |     |           |     |
       |     |           |     +---SUPAPolicyVariable (5.9)
       |     |           |     |
       |     |           |     +---SUPAPolicyOperator (5.10)
       |     |           |     |
       |     |           |     +---SUPAPolicyValue (5.11)
       |     |           |
       |     |           +---SUPAGenericDecoratedComponent (5.12)
       |     |           |
       |     |           +---SUPAPolicyCollection (5.13)
       |     |
       |     +---SUPAPolicySource (5.14)
       |     |
       |     +---SUPAPolicyTarget (5.15)

   (Class of another model called "weak
   encapsulaton", meaning that SUPAPolicyMetadata is integrating into)
       |
       +---SUPAPolicyMetadata (5.16)
             |
             +---SUPAPolicyConcreteMetadata (5.17)
             |
             +---SUPAPolicyMetadataDecorator (5.18)
                  |
                  +---SUPAPolicyAccessMetadataDef (5.19)
                  |
                  +---SUPAPolicyVersionMetadataDef (5.20)

                 Figure 16: Main Classes a subclass can use attributes and
   methods of a superclass, but if the GPIM

   SUPAPolicy is the root of superclass changes, the SUPA class hierarchy. For
   implementations, it
   subclass may break. Another is assumed that SUPAPolicy each time a new object is subclassed from
   required, a class from another model. Note that SUPAPolicyMetadata MAY new subclass must be
   subclassed from the same or (preferably) a different class created. These problems are
   present in the
   external model.

   Classes, attributes, [RFC3460], [4], and relationships [6].

   Composition is an alternative that are marked as
   "mandatory" MUST be part of a conformant implementation (i.e., a
   schema MUST contain these entities). This does not mean provides code that these
   entities must be instantiated; rather it is easier to
   use. This means that they must be
   able to be instantiated. Classes, attributes, composition can provide data models that are
   more resistant to change and relationships easier to use. By using composition,
   we can select just the metadata objects that are marked as "optional" MAY be part needed, instead
   of a conformant
   implementation.

   Unless otherwise stated, all classes (and attributes) having to rely on statically defined in
   this section were abstracted objects. We can even
   create new objects from DEN-ng [2], and a version set of
   them are in existing objects through
   composition. Finally, we can use the process of being added decorator pattern to [5]. However, select
   just the work
   in [5] has been put on hold, attributes and the names behaviors that are required for a given
   instance.

   In [2] and [5], a separate metadata class hierarchy is defined to
   address this problem. This document follows this approach.

4.4.7.2.  Design Approach

   The goal of many the GPIM is to enable metadata to be attached to any
   subclass of SUPAPolicyObject that requires it. Since this is a
   system intended for policy-based management, it therefore makes
   sense to be able to control which metadata is attached to which
   policies dynamically (i.e., at runtime).

   One solution is to use the classes,
   attributes, and relationships are slightly different.

5.2.  The Abstract Class "SUPAPolicyObject" Policy Pattern [1], [2], [6], [12].
   This pattern was built to work with management systems whose
   actions were dependent upon context. The Policy Pattern is a mandatory abstract class. shown
   in Figure 17 shows the
   SUPAPolicyObject class, 16, and its four subclasses.

   A works as follows:

                      Defines
     +----------+     Behavior                  +------------+
     | Policies +----------------+              | SUPAPolicy |
     +----+-----+ 1..n           |              +------+-----+
    0..n / \                     |                    / \ 0..n
          |                      |                     A
  +----------------+/
          |                      |                    \                         \+------------------+
  |SUPAPolicyObject+ A --------------------------+SUPAPolicyMetadata|
  +--------+-------+\ /  SUPAHasPolicyMetadata  /+------------------+ /
          |                1..n \
           I
           I
           +-----------------+----------------+-----------+
           I                 I                I           I
   A       I                 I                I           I
  +--------+------------+    I                I           I /                    | SUPAPolicyStructure
          |    I                I           I
  +---------------------+    I                I           I
            A                I                I           I
           +-----------------+------------+   I           I          +-----------+--------------+      | SUPAPolicyComponentStructure
          |   I           I
           +------------------------------+   I           I
                                     C        I           I
                                    +---------+--------+  I          | SUPAPolicyTarget SUPAPolicyMetadataDetail |  I
                                    +------------------+  I
                                                C         I
                                               +----------+-------+      | SUPAPolicySource
          |          +-----------+--------------+      |
          |                      |                     |
          | Selects              |                     |
          | Policies             |                     |
          |                      |                     |
          |                      +-------------------->+
          |                             Applies        |
         / \                            Behavior       |
          A                                            |
    0..n \ /                                          \ / 0..n
     +----+-----+                             +--------+---------+
     | Context  |                             |SUPAPolicyMetadata|
     +----------+                             +------------------+

                 Figure 17. SUPAPolicyObject and Its Subclasses

   This class 16.  Context-Aware Policy Rules

      o Context is the root of the SUPA class hierarchy. It defines the
   common attributes and relationships that derived from all SUPA subclasses
   inherit.

   A SUPAPolicyObject MAY be qualified by applicable system inputs (e.g.,
        OAMP data from network elements, business goals, time of
        day, geo-location, etc.).
      o Context is then used to select a working set of zero or more
   SUPAPolicyMetadata objects. This Policies.
      o Policies are then used to define behavior at various
        control points in the system.
      o One simple type of control point is provided by an association class.
        Since the
   SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This
   enables association class represents the semantics of the SUPAPolicyObject how
        two classes are related to each other, then
         o ECAPolicyRule actions can be more
   completely specified.

5.2.1.  SUPAPolicyObject Attributes used to change the attribute
           values, methods, and relationships of the association
           class
         o This section defines has the attributes affect of changing how the SUPAPolicyObject class.
   These attributes are inherited by all subclasses of the GPIM
   except for the SUPAPolicyMetadata class, which is a sibling class.

5.2.1.1.  Object Identifiers

   This document defines two class attributes in SUPAPolicyObject,
   called supaPolObjIDContent and supaPolObjIDEncoding, that together
   define a unique object ID. This enables all class instances classes are
           related to be
   uniquely identified.

   One of each other
      o Finally, as context changes, the goals working set of SUPA is policies
        change, enabling the behavior to be able adjusted to generate different data
   models that support different types of protocols and repositories.
   This means that the notion of an object ID must be generic. It is
   inappropriate follow
        changes in context (according to use data modeling concepts, such as keys, Globally
   Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs),
   Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names
   (FQPNs), Uniform Resource Identifiers (URIs), appropriate business goals
        and other similar
   mechanisms, to define the structure factors, of an information model.
   Therefore, course) in a synthetic object ID is closed loop manner.

4.4.7.2.1.  Policies and Actors

   The Policy Continuum ([1] [5] [10] [12]) was defined using these two class
   attributes. This can be used to facilitate mapping to associate
   different data
   model object schemes.

   The two attributes work together, actors with the supaPolObjIDContent
   attribute defining the content different policies at different levels of the object ID
   business and/or technical specificity. Context-aware policy rules,
   and the
   supaPolObjIDEncoding attribute defining how Policy Pattern, were defined to interpret the
   content. These two attributes form a tuple, and together enable
   a machine realize this association.

   Four important functions related to understand the syntax lifecycle of policies are
   design, implementation, deployment, and value execution. There are many
   different possible definitions of an object
   identifier these functions (even for policy
   lifecycle management); however, for the object instance purposes of this class.

   Similarly, all SUPA classes are attributes document,
   they are both uniquely
   named defined as well follows:

      o Design:       The process of defining a software architecture
                      to satisfy user requirements.
      o Development:  the process of documenting, programming,
                      testing, and maintaining code and applications
                      as prepended with part of a software product
      o Deployment:   the prefixes "SUPA" process that assembles and "supa",
   respectively, transfers
                      completed software artifacts to facilitate model integration.

5.2.1.2.  The Attribute "supaPolObjIDContent"

   This is a mandatory string attribute state that represents part
                      enables their execution
      o Execution:    the process of installing, activating, running,
                      and subsequently deactivating executable
                      software products

   The design process is responsible for producing a software
   architecture. This emphasizes the
   object identifier design, as opposed to the
   programming, of an instance software systems. In contrast to design,
   development emphasizes constructing software artifacts via coding
   and documentation.

   Deployment may be described as the process of this class. releasing software.
   It defines the
   content includes all of the object identifier. It works with another class
   attribute, called supaPolObjIDEncoding, which defines how operations required to
   interpret this attribute. These two attributes form assemble a tuple,
   and together enable completed
   software product. It typically also includes the process of
   preparing a machine software product for execution (e.g., assembling a set
   of software products into a larger product, determining if the
   consumer site has appropriate resources to understand install and execute the syntax
   software product, and value
   of an object identifier for collecting information on the object instance feasibility of this class.
   using the software product). This contrasts with the execution
   process, which is based on the DEN-ng class design [2].

5.2.1.3.  The Attribute "supaPolObjIDEncoding"

   This is a mandatory non-zero enumerated integer attribute that
   represents part of the object identifier of an instance set of this
   class. It defines processes that follow deployment.

   In summary, exemplar states in the format of policy lifecycle process
   include:

      o Design:       determining how the object identifier. It works
   with another class attribute, called supaPolObjIDContent, which
   defines policy-based management
                      system will operate
      o Development:  documenting, programming, testing, and
                      maintaining policies and policy components
      o Deployment:   assembling the content components of the object ID. These two attributes form a tuple, policy-based
                      management system
      o Execution:    installing, enabling, running, disabling,
                      and together enable a machine to understand the syntax uninstalling policies and value policy components

4.4.7.2.2.  Deployment vs. Execution of an object identifier Policies

   One of the primary reasons for separating the object instance of
   this class. The supaPolObjIDEncoding attribute deployment and
   execution processes is mapped to the
   following values:

      0:  error
      1:  init
      2:  primary_key
      3:  foreign_key
      4:  GUID
      5:  UUID
      6:  URI
      7:  FQDN
      8:  FQPN
      9:  string_instance_id

   The values 0 and 1 represent an error state differentiate between environments that
   are not ready to execute policies (i.e., deployment) and an initialization
   state, respectively. The value 9 defines the canonical
   representation, in ASCII, of an instance ID of this object.

5.2.1.4.  The Attribute "supaPolicyDescription"

   This is an optional string attribute
   environments that defines a free-form
   textual description of this object.

5.2.1.5.  The Attribute "supaPolicyName" are ready to execute policies (i.e., execution).
   This is an optional string attribute important consideration, since policies that defines are
   related to the name same set of this
   Policy. This enables any existing generic naming attribute to be
   used for generic naming, while allowing this attribute to tasks may be used
   to name Policy entities deployed in many different
   places (e.g., in a common manner. Note that this is NOT
   the same as policy system vs. in a network device). In
   addition, each managed entity in the commonName attribute set of the Policy class defined SUPAPolicyTargets may
   or may not be in [RFC3060], as a state that attribute is intended allows SUPAPolicies to be used with just
   X.500 cn attributes.

5.2.2.  SUPAPolicyObject Relationships

   The SUPAPolicyObject applied to
   it (see section 4.4.6.).

   Hence, this design includes dedicated class currently defines a single relationship,
   as defined in attributes for
   getting and setting the subsection below.

5.2.2.1.  The Aggregation "SUPAHasPolicyMetadata" deployment and execution status, as well
   as enabling and disabling, SUPAPolicies (see section 5.3.1.).

4.4.7.2.3.  Using SUPAMetadata for Policy Deployment and Execution

   One way of encoding deployment and execution status for policies
   and policy components is to attach Metadata objects to affected
   SUPAPolicyStructure and SUPAPolicyComponentStructure objects.
   This provides an extensible and efficient means to describe
   and/or prescribe deployment and/or execution status of a policy
   or a policy component. It is extensible, since classes and
   relationships can be used, as opposed to a mandatory aggregation that defines the set of
   SUPAPolicyMetadata that are aggregated by this particular
   SUPAPolicyObject. This aggregation attributes. It
   is defined in efficient, because the decorator pattern (see section
   5.16.2.

5.2.2.2.  The Association Class "SUPAHasPolicyMetadataDetail"

   This 5.7) is a mandatory concrete association class that defines the
   semantics of the SUPAPolicyMetadata aggregation. This
   used (this enables the attributes and relationships and/or methods of objects, or the SUPAPolicyMetadataDetail class
   entire object, to be used to constrain which SUPAPolicyMetadata objects can be
   aggregated by this particular SUPAPolicyObject instance. This
   association class is defined in Section 5.16.2.2.

5.3.  The Abstract Class "SUPAPolicyStructure"

   This is add characteristics and/or behavior
   to a mandatory abstract class that is used given object.

   SUPAPolicyMetadata objects (see sections 5.16 - 5.20) may be
   attached to represent the
   structure of a SUPAPolicy. This class (and all SUPAECAPolicyRule and/or any of its subclasses)
   is a type of PolicyContainer. SUPAPolicyStructure was abstracted
   from DEN-ng [2], and a version of this class is in the process of
   being added components
   to [5]. However, the version in [5] differs
   significantly. First, the class and relationship definitions ared
   different. Second, [5] uses the composite pattern. Neither of
   these are implemented in this document because define additional semantics of optimizations
   done to the SUPA class hierarchy that are NOT present in [5]. SUPAECAPolicyRule. For this release,
   example, SUPAAccessMetadataDef (see section 5.19) and/or
   SUPAVersionMetadataDef (see section 5.20) may be attached to
   define the only official type access privileges and version information,
   respectively, of a policy rule and/or its components.

   The SUPAPolicyStructure defines an attribute, supaPolDeployStatus,
   (see section 5.3.1.3.) that is
   supported is the event-condition-action (ECA) type of policy rule.
   However, SUPAPolicyMetadata objects can
   use to get and set the structure deployment and execution status of the SUPA hierarchy is defined a
   SUPAPolicy. This allows metadata to
   facilitate adding new types of rules later.

   A SUPAPolicy may take be used to alter the form
   deployment and/or execution state of an individual a policy or (or a set of policies. This requirement is supported by applying the
   composite pattern
   policy components) without having to subclasses affect other parts of the SUPAPolicyStructure class,
   as shown in Figure 5. In this document, this is done for the
   SUPAECAPolicyRule subclass, and results in two subclasses:
   SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and
   SUPAECAPolicyRuleComposite (for defining hierarchies of policies).

   Note that there is no need for a "match strategy attribute"
   policy-based management system. The supaPolDeployStatus attribute
   indicates that
   some models [RFC3460], [4], [6] have; this SUPAPolicy can or cannot be deployed. If it
   cannot be deployed.

   The reverse is because the
   SUPAPolicyStructure class is used just for containment. Hence, the
   containers themselves serve as also true (and hence, forms a closed-loop system
   controlled by metadata). For example, if the scoping component for nested
   policies.

5.3.1.  SUPAPolicyStructure Attributes

   The following subsections define set of deployed
   SUPAPolicies are SUPAECAPolicyRules, then when the attributes actions of
   these SUPAECAPolicyRules are executed, the
   SUPAPolicyStructure class.

   The SUPAPolicyStructure class overall context has a number of attributes that have
   no counterpart
   changed (see section 4.4.7.2). The context manager could then
   change attribute values (directly or indirectly) in the SUPAPolicyComponentStructure
   SUPAPolicyMetadataDetail association class. This is
   because these attributes are only appropriate at class represents
   the level behavior of a
   policy rule, not at the level SUPAHasPolicyMetadata aggregation, which is
   used to define which SUPAPolicyMetadata can be attached to which
   SUPAPolicy objet in this particular context. For example, the
   access privileges of a policy component.

   Care must and/or policy component could be taken in adding attributes
   changed dynamically, according to this class,
   because changes in context.

   By using the behavior of future subclasses decorator pattern on SUPAPolicyMetadata, any number
   of this class (e.g.,
   declarative and functional policies) is very different than the
   behavior SUPAPolicyMetadata objects (or their attributes, etc.) can be
   wrapped around a concrete subclass of SUPAECAPolicyRules.

5.3.1.1.  The Attribute "supaPolAdminStatus" SUPAPolicyMetadata. This is an optional attribute, which is an enumerated non-negative
   integer. It defines
   shown in Figure 17 below.

4.4.7.3.  Structure of SUPAPolicyMetadata

   SUPAPolicyMetadata also uses the current administrative status decorator pattern to provide an
   extensible framework for defining metadata to attach to SUPAPolicy
   subclasses. Its two principal subclasses are
   SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator. The
   former is used to define concrete subclasses of this
   SUPAPolicyClause. Values include:

      0:  error
      1:  init
      2:  enabled
      3:  disabled
      4:  in test (i.e., no operational traffic SUPAPolicyMetadata
   that are attached at runtime to SUPAPolicy subclasses, while the
   latter is used to define concrete objects that represent reusable
   attributes, methods, and relationships that can be passed)

   The values 0 added to
   subclasses of SUPAPolicyConcreteMetadata.

   For example, concepts like identification, access control, and 1
   version information are too complex to represent an error state as a single
   attribute, or even a couple of attributes - they require the
   generic power of objects to represent their characteristics and
   behavior. Furthermore, defining concrete classes to represent
   these concepts in the policy hierarchy is fragile, because:

     1. not all objects that use these concepts need all of the
        information represented by them (e.g., two subclasses of an initialization
   state, respectively. Values 2
        Identification Object may be Passport and 3 mean Certificate, but
        these two objects are rarely used together, and even those
        contexts that this
   SUPAPolicyStructure is administratively enabled or disabled,
   respectively. A value use one of 4 means these classes may not need all of
        the data in that this SUPAPolicyStructure is
   currently class)
     2. defining a class means defining its attributes, methods, and
        relationships at a particular place in the hierarchy; this
        means that defining a special test mode relationship between a class A and
        another class B SHOULD NOT only be used as part done if all of
   an OAM&P policy.

5.3.1.2.  The Attribute "supaPolContinuumLevel"

   This is an optional non-negative integer attribute. It defines the level of abstraction, or policy continuum level [10], of this
   particular SUPAPolicy. The value assignment subclasses
        of this class is
   dependent on B can use the application; however, it is recommended that
   for consistency with other SUPA attributes, the values of 0 and 1
   are reserved for error methods, and initialization states.

   By convention, lower values represent more abstract levels relationships of A
        (e.g., in the
   policy continuum. For above example, defining a value of 1 could represent
   business policy, a value of 2 could represent application-specific
   policies, relationship between
        an Identification Object and a value superclass of 3 could represent low=level policies for
   network administrators.

5.3.1.3.  The Attribute "supaPolDeployStatus"

   This a router class
        is not appropriate, since routers do not use Passports)

   Therefore, an optional enumerated, non-negative integer attribute. The
   purpose of this attribute association class is used to indicate that define the semantics
   of the SUPAHasPolicyMetadata aggregation. This follows the strategy
   defined in Section 4.2.2. Figure 17 illustrates this SUPAPolicy approach. The
   SUPAHasPolicyMetadataDetail association class contains attributes
   that define which SUPAPolicyMetadata objects can
   or cannot be deployed aggregated by the policy management system.
   which SUPAPolicyObjects. This
   attribute also enables the policy manager to know which SUPAPolicies to
   retrieve, and may be useful for
   defined that get and set the policy execution system values of these attributes. (Note that
   for
   planning this approach to work, the staging association class is defined as a
   concrete class.) The multiplicity of SUPAPolicies. Values include:

      0:  error
      1:  init
      2:  deployed and enabled the SUPAHasPolicyMetadata
   aggregation is defined as 0..n - 0..n, which makes this approach
   optional.

   Since a class encapsulates attributes, methods, and behavior,
   defining the Identification Object in the above example as a type
   of SUPAPolicyMetadata object enables the decorator pattern to be
   used to attach all or part of that object to other objects that
   need it.

      A
     +------------------+
     | SUPAPolicyObject |
     +--------+---------+
             / \ 0..n
              A
             \ /
              |                                A
              |                          0..n +--------------------+
              |   SUPAHasPolicyMetadata      \|                    |
              +-------------+-----------------+ SUPAPolicyMetadata |
                            ^                /|                    |
                            |                 +------+------+------+
               C            |                       / \     | 1..n
              +-------------+---------------+        I      |
         0..n |                             |        I      |
   +----------+ SUPAHasPolicyMetadataDetail |        I      |
   |          |                             |        I      |
   |          +-----------------------------+        I      |
   |                                                 I      |
   |          C                                      I      |
   |     0..n +----------------------------+         I      |
   +----------+ SUPAPolicyConcreteMetadata +IIIIIIIII+      |
              +----------------------------+         I      |
                                                     I      |
              A                                      I      |
             +-----------------------------+         I      |
             | SUPAPolicyMetadataDecorator +IIIIIIIII+      |
             +-------+--------------+------+                |
                    / \            / \ 0..1                 |
                     I              A                       |
                     I             \ /                      |
                     I              |                       |
          subclasses for adding     |                       |
          behavior to policies      +-----------------------+
          and policy components      SUPAHasMetadataDecorator

     Figure 17.  SUPAPolicyMetadata Association Class Relationships

   Figure 18 shows a relevant portion of the SUPAPolicyMetadata
   hierarchy. SUPAPolicyConcreteMetadata is a concrete class that
   subclasses of the SUPAPolicyMetadataDecorator class can wrap.
   Two such subclasses, SUPAPolicyAccessMetadataDef and
   SUPAPolicyVersionMetadataDef, are shown in Figure 18. This
   enables access control and version information to be added
   statically (at design time) or dynamically (at runtime) to
   SUPAPolicyConcreteMetadata; this enables metadata-driven systems
   to adjust the behavior of the management system to changes in
   context, business rules, services given to end-users, and other
   similar factors. This is discussed more in sections 5.18 - 5.20.

                  A
                 +--------------------+
                 |                    |  SUPAHasMetadataDecorator
                 | SUPAPolicyMetadata +-------------------+
                 |                    | 1..n              |
                 +---------+----------+                   |
                           I                              |
                           I                              |
                           I                              |
             +-------------+-----------------+            |
             |                               |            |
    C        |                               |           / \
   +---------+------------------+            |            A
   | SUPAPolicyConcreteMetadata |    A       |      0..1 \ /
   +----------------------------+   +--------+------------+-------+
                                    | SUPAPolicyMetadataDecorator |
                                    +------------+----------------+
                                                 I
                  +------------------------------+--------+
                  I                                       I
                  I                                       I
   C              I                  C                    I
  +---------------+-------------+   +---------------------+--------+
  | SUPAPolicyAccessMetadataDef |   | SUPAPolicyVersionMetadataDef |
  +-----------------------------+   +------------------------------+

     Figure 18.  SUPAPolicyMetadata Subclasses and Relationships

5.  GPIM Model
   This section defines the classes, attributes, and relationships of
   the GPIM.

5.1.  Overview
   The overall class hierarchy is shown in Figure 19.

   (Class of another model that SUPA is integrating into)
       |
       +---SUPAPolicyObject (Sec 5.2)
             |
             +---SUPAPolicyStructure (Sec 5.3)
             |
             +---SUPAPolicyComponentStructure (Sec 5.4)
             |     |
             |     +---SUPAPolicyClause (Sec 5.5)
             |     |     |
             |     |     +---SUPAEncodedClause (Sec 5.6)
             |     |
             |     +---SUPAPolicyClauseComponentDecorator (Sec 5.7)
             |           |
             |           +---SUPAPolicyTerm (Sec 5.8)
             |           |     |
             |           |     +---SUPAPolicyVariable (Sec 5.9)
             |           |     |
             |           |     +---SUPAPolicyOperator (Sec 5.10)
             |           |     |
             |           |     +---SUPAPolicyValue (Sec 5.11)
             |           |
             |           +---SUPAGenericDecoratedComponent (Sec 5.12)
             |           |
             |           +---SUPAPolicyCollection (Sec 5.13)
             |           |
             |           +---SUPAPolicyComponentDecorator (Sec 5.14)
             |
             +---SUPAPolicySource (Sec 5.15)
             |
             +---SUPAPolicyTarget (Sec 5.16)

   (Class of another model that SUPAPolicyMetadata is integrating into)
       |
       +---SUPAPolicyMetadata (Sec 5.17)
             |
             +---SUPAPolicyConcreteMetadata (Sec 5.18)
             |
             +---SUPAPolicyMetadataDecorator (Sec 5.19)
                  |
                  +---SUPAPolicyAccessMetadataDef (Sec 5.20)
                  |
                  +---SUPAPolicyVersionMetadataDef (5.20)

                 Figure 19.  Main Classes of the GPIM

   SUPAPolicy is the root of the SUPA class hierarchy. For
   implementations, it is assumed that SUPAPolicy is subclassed from
   a class from another model. Note that SUPAPolicyMetadata MAY be
   subclassed from the same or (preferably) a different class in the
   external model.

   Classes, attributes, and relationships that are marked as
   "mandatory" MUST be part of a conformant implementation (i.e., a
   schema MUST contain these entities). This does not mean that these
   entities must be instantiated; rather it means that they must be
   able to be instantiated. Classes, attributes, and relationships
   that are marked as "optional" MAY be part of a conformant
   implementation. Note that the Single Responsibility Principle [14]
   mandates that subclasses should not change inherited attributes.

   Unless otherwise stated, all classes (and attributes) defined in
   this section were abstracted from DEN-ng [2].

5.2.  The Abstract Class "SUPAPolicyObject"

   This is a mandatory abstract class. Figure 20 shows the
   SUPAPolicyObject class, and its four subclasses.

   A                 0..n                   0..n  A
  +----------------+/ \                         \+------------------+
  |SUPAPolicyObject+ A --------------------------+SUPAPolicyMetadata|
  +--------+-------+\ /  SUPAHasPolicyMetadata  /+------------------+
          / \
           I
           I
           +-----------------+----------------+-----------+
           I                 I                I           I
   A       I                 I                I           I
  +--------+------------+    I                I           I
  | SUPAPolicyStructure |    I                I           I
  +---------------------+    I                I           I
            A                I                I           I
           +-----------------+------------+   I           I
           | SUPAPolicyComponentStructure |   I           I
           +------------------------------+   I           I
                                     C        I           I
                                    +---------+--------+  I
                                    | SUPAPolicyTarget |  I
                                    +------------------+  I
                                                C         I
                                               +----------+-------+
                                               | SUPAPolicySource |
                                               +------------------+

          Figure 20.  SUPAPolicyObject and Its Subclasses

   This class is the root of the SUPA class hierarchy. It defines the
   common attributes and relationships that all SUPA subclasses
   inherit.

   A SUPAPolicyObject MAY be qualified by a set of zero or more
   SUPAPolicyMetadata objects. This is provided by the
   SUPAHasPolicyMetadata aggregation (see Section 5.2.2). This
   enables the semantics of the SUPAPolicyObject to be more
   completely specified.

5.2.1.  SUPAPolicyObject Attributes

   This section defines the attributes of the SUPAPolicyObject class.
   These attributes are inherited by all subclasses of the GPIM
   except for the SUPAPolicyMetadata class, which is a sibling class.

5.2.1.1.  Object Identifiers

   This document defines two class attributes in SUPAPolicyObject,
   called supaPolObjIDContent and supaPolObjIDEncoding, that together
   define a unique object ID. This enables all class instances to be
   uniquely identified.

   One of the goals of SUPA is to be able to generate different data
   models that support different types of protocols and repositories.
   This means that the notion of an object ID must be generic. It is
   inappropriate to use data modeling concepts, such as keys, Globally
   Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs),
   Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names
   (FQPNs), Uniform Resource Identifiers (URIs), and other similar
   mechanisms, to define the structure of an information model.
   Therefore, a synthetic object ID is defined using these two class
   attributes. This can be used to facilitate mapping to different data
   model object schemes.

   The two attributes work together, with the supaPolObjIDContent
   attribute defining the content of the object ID and the
   supaPolObjIDEncoding attribute defining how to interpret the
   content. These two attributes form a tuple, and together enable
   a machine to understand the syntax and value of an object
   identifier for the object instance of this class.

   Similarly, all SUPA classes are attributes are both uniquely
   named as well as prepended with the prefixes "SUPA" and "supa",
   respectively, to facilitate model integration.

5.2.1.2.  The Attribute "supaPolObjIDContent"

   This is a mandatory string attribute that represents part of the
   object identifier of an instance of this class. It defines the
   content of the object identifier. It works with another class
   attribute, called supaPolObjIDEncoding, which defines how to
   interpret this attribute. These two attributes form a tuple,
   and together enable a machine to understand the syntax and value
   of an object identifier for the object instance of this class.
   This is based on the DEN-ng class design [2].

5.2.1.3.  The Attribute "supaPolObjIDEncoding"

   This is a mandatory non-zero enumerated integer attribute that
   represents part of the object identifier of an instance of this
   class. It defines the format of the object identifier. It works
   with another class attribute, called supaPolObjIDContent, which
   defines the content of the object ID. These two attributes form
   a tuple, and together enable a machine to understand the syntax
   and value of an object identifier for the object instance of
   this class. The supaPolObjIDEncoding attribute is mapped to the
   following values:

      0:  error
      1:  init
      2:  primary_key
      3:  foreign_key
      4:  GUID
      5:  UUID
      6:  URI
      7:  FQDN
      8:  FQPN
      9:  string_instance_id

   The values 0 and 1 represent an error state and an initialization
   state, respectively. The value 9 defines the canonical
   representation, in ASCII, of an instance ID of this object.

5.2.1.4.  The Attribute "supaPolicyDescription"

   This is an optional string attribute that defines a free-form
   textual description of this object.

5.2.1.5.  The Attribute "supaPolicyName"

   This is an optional string attribute that defines the name of this
   Policy. This enables any existing generic naming attribute to be
   used for generic naming, while allowing this attribute to be used
   to name Policy entities in a common manner. Note that this is NOT
   the same as the commonName attribute of the Policy class defined
   in [RFC3060], as that attribute is intended to be used with just
   X.500 cn attributes.

5.2.2.  SUPAPolicyObject Relationships

   The SUPAPolicyObject class currently defines a single relationship,
   as defined in the subsection below.

5.2.2.1.  The Aggregation "SUPAHasPolicyMetadata"

   This is a mandatory aggregation that defines the set of
   SUPAPolicyMetadata that are aggregated by this particular
   SUPAPolicyObject. This aggregation is defined in section
   5.16.2.

5.2.2.2.  The Association Class "SUPAHasPolicyMetadataDetail"

   This is a mandatory concrete association class that defines the
   semantics of the SUPAPolicyMetadata aggregation. This enables the
   attributes and relationships of the SUPAPolicyMetadataDetail class
   to be used to constrain which SUPAPolicyMetadata objects can be
   aggregated by this particular SUPAPolicyObject instance. This
   association class is defined in Section 5.16.2.2.

5.3.  The Abstract Class "SUPAPolicyStructure"

   This is a mandatory abstract class that is used to represent the
   structure of a SUPAPolicy. This class (and all of its subclasses)
   is a type of PolicyContainer. SUPAPolicyStructure was abstracted
   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
   significantly. First, the class and relationship definitions ared
   different. Second, [5] uses the composite pattern. Neither of
   these are implemented in this document because of optimizations
   done to the SUPA class hierarchy that are NOT present in [5].

   For this release, the only official type of policy that is
   supported is the event-condition-action (ECA) type of policy rule.
   However, the structure of the SUPA hierarchy is defined to
   facilitate adding new types of rules later.

   A SUPAPolicy may take the form of an individual policy or a set
   of policies. This requirement is supported by applying the
   composite pattern to subclasses of the SUPAPolicyStructure class,
   as shown in Figure 8. In this document, this is done for the
   SUPAECAPolicyRule subclass, and results in two subclasses:
   SUPAECAPolicyRuleAtomic (for defining stand-alone policies) and
   SUPAECAPolicyRuleComposite (for defining hierarchies of policies).

   Note that there is no need for a "match strategy attribute" that
   some models [RFC3460], [4], [6] have; this is because the
   SUPAPolicyStructure class is used just for containment. Hence, the
   containers themselves serve as the scoping component for nested
   policies.

5.3.1.  SUPAPolicyStructure Attributes

   The following subsections define the attributes of the
   SUPAPolicyStructure class.

   The SUPAPolicyStructure class has a number of attributes that have
   no counterpart in the SUPAPolicyComponentStructure class. This is
   because these attributes are only appropriate at the level of a
   policy rule, not at the level of a policy component.

   Care must be taken in adding attributes to this class,
   because the behavior of future subclasses of this class (e.g.,
   declarative and functional policies) is very different than the
   behavior of SUPAECAPolicyRules.

5.3.1.1.  The Attribute "supaPolAdminStatus"

   This is an optional attribute, which is an enumerated non-negative
   integer. It defines the current administrative status of this
   SUPAPolicyClause. Values include:

      0:  error
      1:  init
      2:  enabled
      3:  disabled
      4:  in test (i.e., no operational traffic can be passed)

   The values 0 and 1 represent an error state and an initialization
   state, respectively. Values 2 and 3 mean that this
   SUPAPolicyStructure is administratively enabled or disabled,
   respectively. A value of 4 means that this SUPAPolicyStructure is
   currently in a special test mode and SHOULD NOT be used as part of
   an OAM&P policy.

5.3.1.2.  The Attribute "supaPolContinuumLevel"

   This is an optional non-negative integer attribute. It defines
   the level of abstraction, or policy continuum level [10], of this
   particular SUPAPolicy. The value assignment of this class is
   dependent on the application; however, it is recommended that
   for consistency with other SUPA attributes, the values of 0 and 1
   are reserved for error and initialization states.

   By convention, lower values represent more abstract levels of the
   policy continuum. For example, a value of 1 could represent
   business policy, a value of 2 could represent application-specific
   policies, and a value of 3 could represent low=level policies for
   network administrators.

5.3.1.3.  The Attribute "supaPolDeployStatus"

   This is an optional enumerated, non-negative integer attribute. The
   purpose of this attribute is to indicate that this SUPAPolicy can
   or cannot be deployed by the policy management system. This
   attribute enables the policy manager to know which SUPAPolicies to
   retrieve, and may be useful for the policy execution system for
   planning the staging of SUPAPolicies. Values include:

      0:  error
      1:  init
      2:  deployed and enabled
      3:  deployed and in test
      4:  deployed but not enabled
      5:  ready to be deployed
      6:  cannot be deployed

   The values 0 and 1 represent an error state and an initialization
   state, respectively. A value of 2 means that the policy management
   system MAY use this SUPAPolicy. A value of 3-5 means that the
   policy management system SHOULD NOT use this SUPAPolicy until it is
   put into an enabled state.

5.3.1.4.  The Attribute "supaPolExecFailStrategy"

   This is an optional non-negative, enumerated integer that defines
   what actions, if any, should be taken by this
   SUPAPolicyStructure object if it fails to execute correctly.

   Note that some systems may not be able to support all options
   specified in this enumeration. If rollback is supported by the
   system, then option 2 may be skipped. Options 3 and 4 can be used
   by systems that do and do not support rollback. Values include:

      0:  error
      1:  init
      2:  attempt rollback of all actions taken and stop execution
      3:  attempt rollback of only the action that failed and stop
          execution
      4:  stop execution but do not rollback any actions
      5:  ignore failure and continue execution

   The values 0 and 1 represent an error state and an initialization
   state, respectively. A value of 2 means that ALL execution is
   stopped, rollback of all actions (whether successful or not) is
   attempted, and that SUPAPolicies that otherwise would have been
   executed are ignored. A value of 3 means that execution is stopped,
   and rollback is attempted for ONLY the SUPAPolicy that failed to
   execute correctly. A value of 4 means that execution is stopped, but
   no actions are rolled back. A value of 5 means that the failure is
   ignored, and execution continues.

5.3.2.  SUPAPolicyStructure Relationships

   The SUPAPolicyStructure class owns four relationships, which are
   defined in the following subsections. It also inherits the
   SUPAHasPolicyMetadata aggregation (see section 5.17.2.1.).

5.3.2.1.  The Aggregation "SUPAHasPolicySource"

   This is an optional aggregation, and defines the set of
   SUPAPolicySource objects that are attached to this particular
   SUPAPolicyStructure object. The semantics of this aggregation
   are defined by the SUPAHasPolicySourceDetail association class.
   PolicySource objects are used for authorization policies, as well
   as to enforce deontic and alethic logic.

   The multiplicity of this aggregation is 0..n - 0..n. This means
   that it is an optional aggregation; zero or more SUPAPolicySource
   objects may be aggregated by this SUPAPolicyStructure object,
   and zero or more SUPAPolicyStructure objects may aggregate this
   particular SUPAPolicySource object.

5.3.2.2.  The Association Class "SUPAHasPolicySourceDetail"

   This is an optional concrete association class, and defines the
   semantics of the SUPAHasPolicySource aggregation. The attributes and
   relationships of this class can be used to define which
   SUPAPolicySource objects can be attached to which particular set
   of SUPAPolicyStructure objects.

5.3.2.2.1.  The Attribute "supaPolSrcIsAuthenticated"

   This is an optional Boolean attribute. If the value of this
   attribute is true, then this SUPAPolicySource object has been
   authenticated by this particular SUPAPolicyStructure object.

5.3.2.2.2.  The Attribute "supaPolSrcIsTrusted"

   This is an optional Boolean attribute. If the value of this
   attribute is TRUE, then this particular SUPAPolicySource object
   has been verified to be trusted by this particular
   SUPAPolicyStructure object.

5.3.2.3.  The Aggregation "SUPAHasPolicyTarget"

   This is an optional aggregation, and defines the set of
   SUPAPolicyTargets that are attached to this particular
   SUPAPolicyStructure. The semantics of this aggregation is
   defined by the SUPAHasPolicyTargetDetail association class. The
   purpose of this class is to explicitly identify managed objects
   that will be affected by the execution of one or more SUPAPolicies.

   The multiplicity of this aggregation is 0..n - 0..n. This means
   that it is an optional aggregation; zero or more SUPAPolicyTarget
   objects may be aggregated by this SUPAPolicyStructure object,
   and zero or more SUPAPolicyStructure objects may aggregate this
   particular SUPAPolicyTarget object.

5.3.2.4.  The Association Class "SUPAHasPolicyTargetDetail"

   This is an optional concrete association class, and defines the
   semantics of the SUPAPolicyTargetOf aggregation. The attributes and
   relationships of this class can be used to define which
   SUPAPolicyTargets can be attached to which particular set of
   SUPAPolicyStructure objects.

5.3.2.4.1.  The Attribute "supaPolTgtIsAuthenticated"

   This is an optional Boolean attribute. If the value of this
   attribute is true, then this SUPAPolicyTarget object has been
   authenticated by this particular SUPAPolicyStructure object.

5.3.2.4.2.  The Attribute "supaPolTgtIsEnabled"

   This is an optional Boolean attribute. If its value is TRUE, then
   this SUPAPolicyTarget is able to be used as a SUPAPolicyTarget.
   This means that it meets two specific criteria:

      1. it has agreed to play the role of a SUPAPolicyTarget (i.e.,
         it is willing to have SUPAPolicies applied to it, and
      2. it is able to either process (directly or with the aid of
         a proxy) SUPAPolicies or receive the results of a processed
         SUPAPolicy and apply those results to itself.

5.3.2.5.  The Association "SUPAHasPolExecFailTakeAction"

   This is an optional association that defines which, if any, actions
   should be taken if this SUPAPolicyStructure object instance fails
   to execute correctly. The semantics of this association are defined
   in the SUPAHasPolExecFailTakeActionDetail association class.

   For a given SUPAPolicyStructure object A, this association defines
   a set of policy action objects B to execute if (and only if) the
   SUPAPolicyStructure object A failed to execute correctly. The
   multiplicity of this association is defined as 0..n on the owner
   (A) side and 1..n on the part (B) side. This means that this
   association is optional; if it is instantiated, then at least one
   SUPAPolicyStructure MUST be instantiated by this
   SUPAPolicyStructure object. Similarly, one or more
   SUPAPolicyStructure objects may be associated with this given
   SUPAPolicyStructure object.

5.3.2.6.  The Association Class "SUPAHasPolExecFailTakeActionDetail"

   This is an optional concrete class that defines the semantics for
   the SUPAHasPolExecFailTakeAction association. The attributes and/or
   relationships of this association class can be used to determine
   which policy action objects are executed in response to a failure
   of the SUPAPolicyStructure object instance that owns this
   association. The association defines the set of policy actions from
   one SUPAPolicyStructure object to be executed if another
   SUPAPolicyStructure object fails to execute properly. Figure 21
   illustrates this approach.

      A
     +---------------------------+ 0..n
     |                           +---------------------------------+
     |                           |   SUPAHasPolExecFailTakeAction  |
     |    SUPAPolicyStructure    |/                                |
     |                           + --------------+-----------------+
     |                           |\              ^
     +---------------------------+ 1..n          |
                                                 |
                               C                 |
                              +------------------+-----------------+
                              | SUPAHasPolExecFailTakeActionDetail |
                              +------------------------------------+

        Figure 21.  SUPAHasPolExecFailTakeAction Association

5.3.2.6.1.  The Attribute "supaPolExecFailActionEncoding"

   This is an optional enumerated, non-negative integer attribute
   that defines how to find the set of SUPAPolicyActions contained
   in each element of the supaPolExecFailTakeActionName class
   attribute. Values include:

      0:  error
      1:  init
      2:  URI
      3:  GUID
      4:  UUID
      5:  FQDN
      6:  FQPN
      7:  string
      8:  string_instance_id

   The values 0 and 1 represent an error state and an initialization
   state, respectively. Values 2-6 define a representation for the
   SUPAPolicyAction. A value of 7 defines an ASCII string that
   contains the name of the SUPAPolicyAction to be executed (e.g., to
   be used in a regex search). A value of 8 defines the canonical
   representation, in ASCII, of an instance ID of this object.

5.3.2.6.2.  The Attribute "supaPolExecFailActionName[1..n]"

   This is an optional array of string attributes that identifies the
   set of SUPAPolicyActions to take if the SUPAPolicyStructure object
   that owns this association failed to execute properly. The
   interpretation of this string attribute is defined by the
   supaPolExecFailTakeActionEncoding class attribute. The association
   defines the SUPAPolicyStructure that contains the set of policy
   actions to execute, and this attribute defines which of these
   actions are to be executed. That there is no need to execute a
   SUPAPolicy, since the event and failure have already occurred.
   Note: [1..n] means that this is a multi-valued property that has
   at least one (and possibly more) attributes.

5.3.2.7.  The Aggregation "SUPAHasPolicyClause"

   This is an optional aggregation that defines the set of
   SUPAPolicyClauses that are aggregated by this particular
   SUPAPolicyStructure instance. The semantics of this
   aggregation are defined by the SUPAHasPolicyClauseDetail
   association class.

   Every SUPAPolicyStructure object instance MUST aggregate at
   least one SUPAPolicyClause object instance. However, the
   converse is NOT true. For example, a SUPAPolicyClause could be
   instantiated and then stored for later use in a policy repository.
   Furthermore, the same SUPAPolicyClause could be used by zero or
   more SUPAPolicyStructure object instances at a given time. Thus,
   the multiplicity of this aggregation is defined as 0..1 on the
   aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the
   part (i.e., the SUPAPolicyClause side). This means that at
   least one SUPAPolicyClause MUST be aggregated by this
   SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may
   be aggregated by this particular SUPAPolicyStructure object.

5.3.2.8.  The Association Class "SUPAHasPolicyClauseDetail"

   This is an optional abstract association class, and defines the
   semantics of the SUPAHasPolicyClause aggregation. The attributes
   and/or relationships of this association class can be used to
   determine which SUPAPolicyClauses are aggregated by which
   SUPAPolicyStructure objects.

5.4.  The Abstract Class "SUPAPolicyComponentStructure"

   This is a mandatory abstract class. It is the superclass of all
   objects that represent different types of components of a
   SUPAPolicy. Different types of policies have different types of
   structural components. This is accommodated by defining two generic
   abstract subclasses, called SUPAPolicyClause and
   SUPAPolicyClauseComponentDecorator, which are both common to
   different policy types. These two classes represent convenient
   control points for defining characteristics and behavior that are
   common to objects that serve as components of a SUPAPolicy.

   SUPAPolicyClause defines a basic building block for writing
   parts of a SUPAPolicy. It is analogous to a clause in a sentence.
   For example, in an ECA Policy Rule, the Event, Condition, and Action
   clauses are each made up of at least one (concrete subclass of a)
   SUPAPolicyClause. Similalry, declarative Policy Rules can also be
   defined using (its own subclasses of) SUPAPolicyClauses. This class
   is defined in section 5.5.

   SUPAPolicyClauseComponentDecorator implements the decorator
   pattern [11]. The decorator pattern enables all or part of one or
   more objects to "wrap" another concrete object (as described in
   Section 4.2.1.2). This enables the definition of an extensible set
   of subclasses that can augment the definition of a SUPAPolicyClause.
   This class is defined in section 5.7.

   Note that there are significant differences between the definition
   of the SUPAPolicyComponentStructure class, and its attributes and
   relationships, and the definition of the corresponding class (and
   its attributes and relationships) in [5].

5.4.1.  SUPAPolicyComponentStructure Attributes

   No attributes are currently defined for this class.

5.4.2.  SUPAPolicyComponentStructure Relationships

   SUPAPolicyComponentStructure participates in a single relationship,
   SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. It
   also inherits the SUPAHasPolicyMetadata aggregation
   (see section 5.17.2.1.).

5.5.  The Abstract Class "SUPAPolicyClause"

   This is a mandatory abstract class that separates the
   representation of a SUPAPolicy from its implementation.
   SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction
   is missing in [RFC3060], [RFC3460], [4], and [6]. This class is
   called PolicyStatement in [5], but the class and relationship
   definitions differ significantly from the corresponding designs
   in this document.

   A SUPAPolicy, regardless of its structure and semantics, can be
   abstracted into a set of sentences. Each sentence can in turn be
   abstracted into a set of clauses. A SUPAPolicyClause is, as its
   name implies, a clause (i.e., a part of a statement), and defines
   the content of a SUPAPolicy. The decorator pattern is used to
   enable an extensible set of objects to "wrap" the SUPAPolicyClause;
   this enables the contents of a SUPAPolicyClause to be adjusted
   dynamically at runtime without affecting other objects.

   This document defines two different types of policy clauses:
   SUPAEncodedClause (which is generic, and can be used by any
   type of policy), and SUPABooleanClause (which is also generic,
   but is typically used by SUPAECAPolicyRule objects, since it is
   used specifically to represent Boolean clauses).

   SUPAPolicyClauses are objects in their own right, which
   facilitates their reuse. SUPAPolicyClauses can aggregate a set
   of any of the subclasses of SUPAPolicyClauseComponentDecorator; this
   was shown in Figures 12 and 13. These five subclasses (i.e.,
   SUPAPolicyTerm, SUPAGenericDecoratedComponent, SUPAECAComponent,
   SUPACollection, and SUPAPolicyComponentDecorator) provide several
   different ways to construct a SUPAPolicyClause:

     1) a SUPAPolicyClause can be made up of a set of three
        SUPAPolicyTerms, which enables constructing an expression
        consiting of a {variable, operator, value} 3-tuple, for
        building SUPAPolicyClauses
     2) a SUPAPolicyClause can be made up of one or more
        SUPAEncodedClauses, which enables a SUPAPolicyClause to be
        formed as an encoded object (e.g., to pass YANG or CLI code)
     3) a SUPAPolicyClause can be made up of a set of SUPACollections,
        which define a Collection (e.g., set, bad, associative arrays)
        of objects that can be assembled into SUPAPolicyClauses after
        further processing
     4) a SUPAPolicyClause can be made up of one or more
        SUPAECAComponents, which enables a SUPAPolicyClause to be
        formed using (reusable) Event, Condition, and/or Action objects
     5) any or all of the above methods can be augmented with more
        complex decorated structures using SUPAPolicyComponentDecorator

   SUPAPolicyClauses are formed by aggregating a set of concrete
   subclasses of the SUPAPolicyClauseComponentDecorator class using the
   SUPAPolicyClauseHasDecorator aggregation (see Figure 12). The
   resulting SUPAPolicyClause is then aggregated by a concrete
   subclass of the SUPAPolicyStructure class, which enables a
   SUPAPolicy to be made up of one or more SUPAPolicyClauses.

5.5.1.  SUPAPolicyClause Attributes

   This section defines the attributes of the SUPAPolicyClause
   class, which are inherited by all SUPAPolicyClause subclasses.

5.5.1.1. The Attribute "supaPolClauseDeployStatus"

   This is an optional enumerated, non-negative integer attribute. The
   purpose of this attribute is to indicate that this SUPAPolicyClause
   can or cannot be deployed by the policy management system. This
   attribute enables the policy manager to know which SUPAPolicyClauses
   to retrieve, and may be useful for the policy execution system for
   planning the staging of SUPAPolicies. Values include:

      0:  error
      1:  init
      2:  deployed and enabled
      3:  deployed and in test
      4:  deployed but not enabled
      5:  ready to be deployed
      6:  cannot be deployed

   The values 0 and 1 represent an error state and an initialization
   state, respectively. If the value of this attribute is 0 or 6, then
   the policy management system SHOULD ignore this SUPAPolicy.
   Otherwise, the policy management system MAY use this SUPAPolicyClause
   (once this SUPAPolicyClause is deployed and enabled). However, a
   value of 4 means that this policy is not admininstratively enabled
   for use and SHOULD NOT be used in OAM&P policies.

5.5.2.  SUPAPolicyClause Relationships

   SUPAPolicyClause participates in two relationships. The first,
   SUPAHasPolicyClause, was defined in section 5.3.2.7. The second,
   SUPAPolicyClauseHasDecorator, is defined below. Note that
   SUPAPolicyClause uses the SUPAPolicyClauseHasDecorator aggregation
   to implement the decorator pattern; this enables a SUPAPolicyClause
   to be "wrapped" with instances of the (concrete) subclasses of the
   SUPAPolicyClauseComponentDecorator object.

5.5.2.1.  The Aggregation "SUPAPolicyClauseHasDecorator"

   This is a mandatory aggregation, and is part of a decorator
   pattern. It is used to enable a concrete instance of a
   SUPAPolicyClauseComponentDecorator to dynamically add behavior to a
   specific type (of concrete subclass) of a SUPAPolicyClause object.
   The semantics of this aggregation are defined by the
   SUPAPolicyClauseHasDecoratorDetail association class.

   The multiplicity of this aggregation is 0..n - 0..n. This means
   that a SUPAPolicyClause does not have to be decorated; however, if
   it is, then zero or more concrete subclasses of the
   SUPAPolicyClauseComponentDecorator class may be used to decorate
   the concrete subclass of SUPAPolicyClause.

5.5.2.2.  The Association Class "SUPAPolicyClauseHasDecoratorDetail"

   This is a mandatory concrete association class, and defines the
   semantics of the SUPAPolicyClauseHasDecorator aggregation. The
   purpose of this class is to use the Decorator pattern to determine
   which SUPAPolicyClauseComponentDecorator object instances, if any,
   are required to augment the functionality of the concrete subclass
   of the SUPAPolicyClause that is being used.

   Currently, there are two attributes defined for this class, which
   are described in the following subsections. Both attributes are
   used in this association class to **constrain the relationship**
   between the concrete subclass of SUPAPolicyClauseComponentDecorator
   that is wrapping the concrete subclass of SUPAPolicyClause. Note
   that class attributes of SUPAPolicyClauseComponentDecorator (see
   section 5.9.2) only affect that specific subclass.

5.5.2.2.1.  The Attribute "supaPolClauseDecConstraintEncoding"

   This is a mandatory non-negative enumerated integer that defines
   how to interpret each string in the supaPolClauseDecConstraint
   class attribute. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  deployed  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text

   Enumerations 0 and 1 signify an error state and an initialization
   state, respectively. Enumerations 2-4 are dedicated to OCL (with
   OCL 2.4 being the latest version as of this writing). QVT defines a
   set of languages [20] (the two most powerful and useful are defined
   by enumerations 5 and 6). Alloy is a language for describing
   constraints, and uses a SAT solver to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but is included for completeness.

5.5.2.2.2.  The Attribute "supaPolClauseDecConstraint[0..n]"

   This is a mandatory array of string attributes. Each attribute
   specifies a constraint to be applied using the encoding defined in
   the supaPolCompConstraintEncoding class attribute. This provides
   a more rigorous and flexible treatment of constraints than is
   possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that
   this is a multi-valued property that may have zero or
   more attributes.

5.6.  The Concrete Class "SUPAEncodedClause"

   This is a mandatory concrete class that refines the behavior of a
   SUPAPolicyClause.

   This class defines a generalized extension mechanism for
   representing SUPAPolicyClauses that have not been modeled with
   other SUPAPolicy objects. This class encodes the contents of the
   policy clause directly into the attributes of the SUPAEncodedClause.
   Hence, SUPAEncodedClause objects are reusable at the object level,
   whereas SUPABooleanClause clauses are reusable at the individual
   Boolean expression level.

   This class uses two of its attributes (supaEncodedClauseContent and
   supaEncodedClauseEncoding) for defining the content and type of
   encoding used in a given SUPAPolicyClause. The benefit of a
   SUPAEncodedClause is that it enables direct encoding of the text of
   the SUPAPolicyClause, without having the "overhead" of using other
   objects. However, note that while this method is efficient, it
   does not reuse other SUPAPolicy objects. Furthermore, its potential
   for reuse is reduced, as only SUPAPolicies that can use the exact
   encoding of this clause can reuse this object.

5.6.1.  SUPAEncodedClause Attributes

   This section defines the attributes of the SUPAEncodedClause class.
   Prescriptive and/or descriptive information about the usage of this
   SUPAEncodedClause may be provided by one or more SUPAPolicyMetadata
   objects, which are each attached to the object instance of this
   SUPAEncodedClause.

5.6.1.1.  The Attribute "supaEncodedClauseContent"

   This is a mandatory string attribute, and defines the content of
   this clause. It works with another class attribute, called
   supaEncodedClauseEncoding, which defines how to interpret the
   value of this attribute (e.g., as a string or reference). These
   two attributes form a tuple, and together enable a machine to
   understand the syntax and value of this object instance.

5.6.1.2.  The Attribute "supaEncodedClauseEncoding"

   This is a mandatory non-negative integer attribute, and defines
   how to interpret the value of the supaEncodedClauseContent. It
   works with another class attribute (supaEncodedClauseContent),
   which defines the content of the encoded clause. These two
   attributes form a tuple, and together enable a machine to
   understand the syntax and value of the encoded clause for the
   object instance of this class. This attribute is NOT required in test
   all data model implementations. Values include:

      0:  error (i.e., an error state)
      1:  init (i.e., an initialization state)
      2:  primary_key
      3:  foreign_key
      4:  deployed but not enabled  GUID
      5:  ready to be deployed  UUID
      6:  cannot be deployed  URI
      7:  FQDN
      8:  FQPN
      9:  string_instance_id

   The values 0 and 1 represent an error state and an initialization
   state, respectively. A The value of 2 means that 9 defines the policy management
   system MAY use this SUPAPolicy. A value canonical
   representation, in ASCII, of an instance ID of 3-5 means that the
   policy management system SHOULD NOT use this SUPAPolicy until it object.

5.6.1.3.  The Attribute "supaEncodedClauseLanguage"

   This is
   put into mandatory non-negative integer attribute, and defines
   the type of language used in this encoded clause. Values include:

      0:  error
      1:  init
      2:  Text
      3:  YANG
      4:  XML
      5:  TL1

   The values 0 and 1 represent an enabled state.

5.3.1.4. error state and an initialization
   state, respectively.

5.6.1.4.  The Attribute "supaPolExecFailStrategy" "supaEncodedClauseResponse"

   This is an optional non-negative, enumerated integer Boolean attribute that defines
   what actions, if any, should emulates a Boolean
   response of this clause, so that it may be taken by combined with other
   subclasses of the SUPAPolicyClause that provide a status as to
   their correctness and/or evaluation state. This enables this
   SUPAPolicyStructure
   object if it fails to execute correctly. be used to construct more complex Boolean clauses.
   Note that some systems may not this attribute does NOT have to be able implemented by all
   data model implementations (e.g., [15]).

5.6.2.  SUPAEncodedClause Relationships

   SUPAPolicyClause participates in two inherited relationships. These
   are SUPAHasPolicyClause, as defined in section 5.3.2.7, and
   SUPAPolicyClauseHasDecorator, as defined in section 5.7.2.

5.7.  The Abstract Class "SUPAPolicyClauseComponentDecorator"

   This is a mandatory class, and is used to support implement the decorator
   pattern. The decorator pattern enables all options
   specified or part of one or more
   objects to "wrap" another concrete object. This means that any
   any concrete subclass of SUPAPolicyClause can be wrapped by any
   concrete subclass of SUPAPolicyClauseComponentDecorator, as shown in
   Figure 22 below.

                         SUPAHasPolicyClause
              +----------------+----------------------------+
              |                ^                            |
              |                |                            |
              |   C            |                            |
              |  +-------------+----------------------+     |
              |  | SUPAPolicyClauseHasDecoratorDetail |     |
              |  +-------------+----------------------+     |
              |                                             |
              |                                             |
             / \                                            |
              A                                             |
      A      \ / 0..n          A                           \ / 1..n
     +--------+-----------+     +---------------------------+--------+
     |  SUPAPolicyClause  |     | SUPAPolicyClauseComponentDecorator |
     +----------+---------+     +--------------+---------------------+
                I                              I
                I                              I
               / \                            / \
         Concrete Subclasses,          Concrete Subclasses
      (e.g., SUPAEncodedClause)     (e.g., SUPAPolicyEvent)
       that are being wrapped        that are the wrapping object(s)

          Figure 22.  SUPAPolicyClauseComponentDecorator

   The SUPAHasPolicyClause aggregation enables one or more concrete
   subclasses of SUPAPolicyClauseComponentDecorator to wrap a concrete
   subclass of SUPAPolicyClause. Its semantics are defined by the
   SUPAPolicyClauseHasDecoratorDetail association class.

5.7.1.  SUPAPolicyClauseComponentDecorator Attributes

   Currently, there are two attributes defined for this enumeration. If rollback is supported class, which
   are described in the following subsections. Both attributes are
   used by subclasses to **constrain the
   system, then option 2 may be skipped. Options 3 and 4 behavior of that subclass**;
   they do **not** affect the relationship between the concrete
   subclass of SUPAPolicyClauseComponentDecorator that is wrapping
   the concrete subclass of SUPAPolicyClause.

   This is different than the use of similar attributes defined in
   the SUPAPolicyClauseHasDecoratorDetail association class. The
   attributes of SUPAPolicyClauseComponentDecorator are used to
   constrain the (concrete subclass of) SUPAPolicyClause that this
   SUPAPolicyClauseComponentDecorator is wrapping. In contrast, the
   attributes of SUPAPolicyClauseHasDecoratorDetail are used to
   define which concrete subclasses of SUPAPolicyClause can be used wrapped
   by systems which concrete subclasses of SUPAPolicyClauseComponentDecorator.

5.7.1.1.  The Attribute "supaPolClauseConstraintEncoding"

   This is a mandatory non-negative enumerated integer that do and do not support rollback. defines
   how to interpret each string in the supaPolCompConstraint class
   attribute. Values include:

     0:  error
     1:  init
     2:  attempt rollback of all actions taken and stop execution  OCL 2.4
     3:  attempt rollback of only the action that failed and stop
          execution  OCL 2.x
     4:  stop execution but do not rollback any actions  OCL 1.x
     5:  ignore failure and continue execution

   The values  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text

   Enumerations 0 and 1 represent signify an error state and an initialization
   state, respectively. A value Enumerations 2-4 are dedicated to OCL (with
   OCL 2.4 being the latest version as of 2 means that ALL execution this writing). QVT defines a
   set of languages [20] (the two most powerful and useful are defined
   by enumerations 5 and 6). Alloy is
   stopped, rollback a language for describing
   constraints, and uses a SAT solver to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but is included for completeness.

5.7.1.2.  The Attribute "supaPolClauseConstraint[0..n]"

   This is a mandatory array of all actions (whether successful or not) string attributes. Each attribute
   specifies a constraint to be applied using the encoding defined in
   the supaPolCompConstraintEncoding class attribute. This provides
   a more rigorous and flexible treatment of constraints than is
   attempted,
   possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that SUPAPolicies
   this is a multi-valued property that otherwise would may have been
   executed are ignored. zero or
   more attributes.

5.7.2.  SUPAPolicyClauseComponentDecorator Relationships

   This class currently participates in two relationships. The first,
   SUPAPolicyClauseHasDecorator, was defined in Section 5.5.2. The
   second, SUPAHasDecoratedPolicyComponent, is defined in
   Section 5.14.2.

5.7.3.  Illustration of Constraints in the Decorator Pattern

   Figure 23 builds a simple SUPAPolicyClause that has both types
   of relationships, and illustrates how the different constraints
   defined in sections 5.7.2 (class attribute constraints) and section
   5.7.3 (relationship constraints) can be used.

    A value                               A
   +----------------+         0..1 +----------------------------------+
   |                | 1..n      / \|                                  |
   |SUPAPolicyClause+------+---- A +SUPAPolicyClauseComponentDecorator|
   |                |      ^    \ /|                                  |
   +---------+------+      |       +-----------+----------------------+
            / \            |                  / \
             I             |                   I
             I             |                   I
     C       I             |          C        I
    +--------+--------+    |         +---------+---------+
    |SUPAEncodedClause|    |         |  SUPAPolicyEvent  |
    +-----------------+    |         +-------------------+
                           |
            C              |
           +---------------+------------+
           |SUPAPolicyHasDecoratorDetail|
           +----------------------------+

          Figure 23.  Constraints in the Decorator Pattern

   Figure 23 says that a SUPAPolicyClause, realized as a
   SUPAEncodedClause object, is wrapped by a
   SUPAPolicyClauseComponentDecorator, realized as a SUPAPolicyEvent
   object. The attributes in the SUPAPolicyClauseComponentDecorator
   object, which are inherited by the SUPAPolicyEvent object, are
   used to constrain the behavior of 3 means the SUPAPolicyEvent object.

   Put another way, the SUPAPolicyClauseHasDecorator aggregation
   enables a concrete subclass of SUPAPolicyClause to be decorated by
   concrete subclasses of SUPAPolicyClauseComponentDecorator. The
   decorator pattern is implemente by the
   SUPAHasDecoratedPolicyComponent aggregation. Hence, attributes in
   the SUPAHasDecoratedPolicyComponentDetail association class are used
   to contrain the behavior of the decorator (e.g., restricting which
   concrete subclasses of the SUPAPolicyComponentDecorator can be used
   as decorators). For example, the attributes in the
   SUPAPolicyClauseComponentDecorator class, when instantiated in an
   instance of a concrete subclass, could restrict which
   SUPAPolicyEvent objects are allowed to be used with which
   SUPAEncodedClause objects.

5.8.  The Abstract Class "SUPAPolicyTerm"

   This is a mandatory abstract class that execution is stopped,
   and rollback is attempted for ONLY the parent of
   SUPAPolicy objects that failed can be used to
   execute correctly. A define a standard way to
   test or set the value of 4 means that execution is stopped, but
   no actions are rolled back. A value a variable. It does this by defining a
   3-tuple, in the form {variable, operator, value}, where each
   element of 5 means that the failure 3-tuple is
   ignored, and execution continues.

5.3.2.  SUPAPolicyStructure Relationships

   The SUPAPolicyStructure class owns four relationships, which are defined in by a concrete subclass of the following subsections.

5.3.2.1.  The Aggregation "SUPAHasPolicySource"

   This is an optional aggregation,
   appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator,
   and defines the SUPAPolicyValue classes, respectively). For example, a
   generic test or set of
   SUPAPolicySource objects that are attached to this particular
   SUPAPolicyStructure object. The semantics the value of a variable is expressed as:

      {variable, operator, value}.

   For event and condition clauses, this aggregation
   are defined by the SUPAHasPolicySourceDetail association class.
   PolicySource objects are used for authorization policies, is typically as well written above
   (e.g., does variable = value); for action clauses, it is typically
   written as <operator> <variable> <value> (e.g., SET var to enforce deontic and alethic logic.

   The multiplicity of this aggregation 1). A
   class diagram is 0..n - 0..n. This means shown in Figure 24.

                         A
                        +----------------+
                        | SUPAPolicyTerm |
                        +--------+-------+
                                / \
                                 I
                                 I
                                 I
               +-----------------+---+--------------------+
               I                     I                    I
               I                     I                    I
       C       I             C       I             C      I
      +--------+---------+  +--------+---------+  +-------+-------+
      |SUPAPolicyVariable|  |SUPAPolicyOperator|  |SUPAPolicyValue|
      +------------------+  +------------------+  +---------------+

            Figure 24.  SUPAPolicyTerm Class Hierarchy

   Note that it is an optional aggregation; zero or more SUPAPolicySource
   objects may be aggregated by this SUPAPolicyStructure object, generic test and zero or more SUPAPolicyStructure set expressions do not have to only use
   objects may aggregate this
   particular SUPAPolicySource object.

5.3.2.2.  The Association Class "SUPAHasPolicySourceDetail"

   This is an optional concrete association class, and defines the
   semantics that are subclasses of SUPAPolicyTerm. For example, the SUPAHasPolicySource aggregation. The attributes and
   relationships
   supaGenericDecoratedCompContent attribute of this class can the
   SUPAGenericDecoratedComponent could be used to define which
   SUPAPolicySource objects can be attached to which particular set as the variable (or the
   value) term of SUPAPolicyStructure objects.

5.3.2.2.1.  The Attribute "supaPolSrcIsAuthenticated"

   This a get or set expression that is an optional Boolean attribute. If in the value above form.

   Hence, the utility of this
   attribute is true, then this SUPAPolicySource object has been
   authenticated by this particular SUPAPolicyStructure object.

5.3.2.2.2.  The Attribute "supaPolSrcIsTrusted"

   This is an optional Boolean attribute. If the value subclasses of this
   attribute SUPAPolicyTerm is TRUE, then this particular SUPAPolicySource object
   has been verified in the
   ability of its subclasses to be trusted by this particular
   SUPAPolicyStructure object.

5.3.2.3.  The Aggregation "SUPAHasPolicyTarget" define a generic framework for
   implementing get and set expressions. This is an optional aggregation, in contrast to
   previous designs (e.g., [RFC3460] and defines the [6]), which depended on
   defining a broad set of
   SUPAPolicyTargets that are attached to this particular
   SUPAPolicyStructure. The semantics subclasses of PolicyVariable and
   PolicyValue. (Note that [4] does not have this aggregation is
   defined by generic capability).

5.8.1.  SUPAPolicyTerm Attributes

   Currently, SUPAPolicyTerm defines a single attribute, as described
   in the SUPAHasPolicyTargetDetail association class. The
   purpose following subsection. Constraints on the subclasses of this
   SUPAPolicyTerm can be applied in two different ways:

     1. use SUPAPolicyComponentDecorator attributes to constrain
        just that individual subclass, and/or
     2. use SUPAHasDecoratedPolicyComponentDetail association class is
        attributes to explicitly identify managed objects
   that will be affected by constrain the relationship between the execution of one or more SUPAPolicies.

   The multiplicity of this aggregation is 0..n - 0..n. This means
   that it is an optional aggregation; zero or more SUPAPolicyTarget
   objects may be aggregated by this SUPAPolicyStructure object,
   and zero or more SUPAPolicyStructure objects may aggregate this
   particular SUPAPolicyTarget object.

5.3.2.4.  The Association Class "SUPAHasPolicyTargetDetail"

   This is an optional concrete association class,
        subclass of SUPAPolicyClause and defines the
   semantics concrete subclass of
        the SUPAPolicyTargetOf aggregation. The attributes and
   relationships of SUPAPolicyTerm class; this class can be used to define determines which
   SUPAPolicyTargets concrete
        subclasses of SUPAPolicyTerm can be attached used to which construct this
        particular set of
   SUPAPolicyStructure objects.

5.3.2.4.1. SUPAPolicyClause.

5.8.1.1.  The Attribute "supaPolTgtIsAuthenticated" "supaPolTermIsNegated"

   This is an optional a mandatory Boolean attribute. If the value of this
   attribute is true, then this SUPAPolicyTarget object has been
   authenticated by this particular SUPAPolicyStructure object.

5.3.2.4.2. SUPAPolicyTerm subclass
   (which represents a term) is negated; otherwise, it is not.

5.8.2.  SUPAPolicyTerm Relationships

   Currently, no dedicated relationships are defined for the
   SUPAPolicyTerm class (as there are in [RFC3460] and [6]) that
   aggregate policy variable and policy value objects into a policy
   rule). This is:

     1) to enable the subclasses of SUPAPolicyTerm to be used by
        other SUPAPolicyComponentDecorator objects, and
     2) because the decorator pattern replaces how such relationships
        were used in [RFC3460] and [6].

   SUPAPolicyTerm, and its subclasses, inherit the
   SUPAPolicyClauseHasDecorator aggregation, which was defined in
   Section 5.5.2, as well as the SUPAHasDecoratedPolicyComponent
   aggregation, which was defined in section 5.7.3.

5.9.  The Attribute "supaPolTgtIsEnabled" Concrete Class "SUPAPolicyVariable"

   This is an optional Boolean attribute. a mandatory concrete class that defines information that
   forms a part of a SUPAPolicyClause. It specifies a concept or
   attribute that represents a variable, which should be compared to
   a value, as specifed in this SUPAPolicyClause. If it is used in
   a SUPAECAPolicyRule, then its value MAY be able to be changed at
   any time, including run-time, via use of the decorator pattern.
   This is TRUE, then
   this SUPAPolicyTarget not possible in previous designs ([RFC3460, [4], and [6]).

   The value of a SUPAPolicyVariable is able typically compared to the
   value of a SUPAPolicyValue using the type of operator defined in
   a SUPAPolicyOperator. However, other objects may be used as instead
   of a SUPAPolicyTarget.
   This means that it meets two specific criteria:

      1. it has agreed SUPAPolicyValue object, and other operators may be defined
   in addition to play those defined in the role SUPAPolicyOperator class.

   SUPAPolicyVariables are used to abstract the representation of a SUPAPolicyTarget (i.e.,
         it is willing
   SUPAPolicyClause from its implementation. Some SUPAPolicyVariables
   are restricted in the values and/or the data type that they may
   be assigned. For example, port numbers cannot be negative, and
   they cannot be floating-point numbers. These and other constraints
   may be defined in two different ways:

     1. use SUPAPolicyClauseComponentDecorator attributes to have SUPAPolicies applied constrain
        just that individual object, and/or
     2. use the SUPAPolicyClauseHasDecoratorDetail association class
        attributes to it, constrain the relationship between the concrete
        subclass of SUPAPolicyClause and
      2. it is able the concrete subclass of
        the SUPAPolicyVariable class

   Please refer to either process (directly or with the aid examples in section 7, which show how to
   restrict the value, data type, range, and other semantics of the
   SUPAPolicyVariable when used in a proxy) SUPAPolicies or receive SUPAPolicyClause.

5.9.1.  Problems with the results RFC3460 Version of PolicyValue

   Please see Appendix A for a processed
         SUPAPolicy and apply those results to itself.

5.3.2.5. detailed comparison.

5.9.2.  SUPAPolicyVariable Attributes

   SUPAPolicyVariable defines one attribute, as described below.

5.9.2.1.  The Association "SUPAHasPolExecFailTakeAction" Attribute "supaPolVarName"

   This is an optional association string attribute that defines which, if any, actions
   should be taken if this SUPAPolicyStructure object instance fails
   to execute correctly. The semantics of this association are defined
   in contains the SUPAHasPolExecFailTakeActionDetail association class.

   For a given SUPAPolicyStructure object A, name of
   this association defines
   a set SUPAPolicyVariable. This variable name forms part of policy action objects B to execute if (and only if) the
   SUPAPolicyStructure object A failed to execute correctly. The
   multiplicity
   {variable, operator, value} canonical form of this association is a SUPAPolicyClause.

5.9.3.  SUPAPolicyVariable Relationships

   Currently, no relationships are defined as 0..n on for the owner
   (A) side and 1..n on SUPAPolicyVariable
   class (note that the part (B) side. decorator pattern obviates the need for
   relationships such as those defined in [RFC3460] and [6]). This means that this
   association is optional; if it is instantiated, then at least one
   SUPAPolicyStructure MUST be instantiated by this
   SUPAPolicyStructure object. Similarly, one or more
   SUPAPolicyStructure objects may be associated with this given
   SUPAPolicyStructure object.

5.3.2.6.
   because SUPAPolicyVariable, and its subclasses, inherit the
   SUPAHasDecoratedPolicyComponent aggregation, which was defined in
   section 5.7.3.

5.10.  The Association Concrete Class "SUPAHasPolExecFailTakeActionDetail" "SUPAPolicyOperator"

   This is an optional a mandatory concrete class that defines the semantics for
   the SUPAHasPolExecFailTakeAction association. The attributes and/or
   relationships modeling different types of this association class can be used to determine
   which policy action objects
   operators that are executed used in response to a failure SUPAPolicyClause.

   The restriction of the SUPAPolicyStructure object instance that owns this
   association. The association relates type of operator used in a SUPAPolicyClause
   restricts the policy actions from one
   SUPAPolicyStructure B to semantics that can be executed if a SUPAPolicyStructure A
   fails expressed in that
   SUPAPolicyClause. It is typically used with SUPAPolicyVariables
   and SUPAPolicyValues to execute properly. Figure 18 illustrates this approach. form a SUPAPolicyClause.

5.10.1.  Problems with the RFC3460 Version

   Please see Appendix A
     +---------------------------+ 0..n
     |                           +---------------------------------+
     |                           |   SUPAHasPolExecFailTakeAction  |
     |    SUPAPolicyStructure    |/                                |
     |                           + --------------+-----------------+
     |                           |\              ^
     +---------------------------+ 1..n          |
                                                 |
                               C                 |
                              +------------------+-----------------+
                              | SUPAHasPolExecFailTakeActionDetail |
                              +------------------------------------+

        Figure 18.  SUPAHasPolExecFailTakeAction Association

5.3.2.6.1. for a detailed comparison.

5.10.2.  SUPAPolicyOperator Attributes

   Currently, SUPAPolicyOperator defines a single generic attribute,
   as described below.

5.10.2.1.  The Attribute "supaPolExecFailActionEncoding" "supaPolOpType"

   This is an optional enumerated, a mandatory non-negative enumerated integer attribute that defines how to find specifies
   the set various types of SUPAPolicyActions contained operators that are allowed to be used in each element of the supaPolExecFailTakeActionName class
   attribute. this
   particular SUPAPolicyClause. Values include:

     0:  error
     1:  init
     2:  URI  Greater than
     3:  GUID  Greater than or equal to
     4:  UUID  Less than
     5:  FQDN  Less than or equal to
     6:  FQPN  Equal to
     7:  string  Not equal to
     8:  string_instance_id

   The values  IN
     9:  NOT IN
    10:  SET
    11:  CLEAR (0 for integers, "" for strings, FALSE for Booleans)
    12:  BETWEEN (inclusive)
    13:  regular expression, PERL-based
    14:  regular expression, POSIX-based (BRE, basic)
    15:  regular expression, POSIX-based (ERE, extended)

   Note that 0 and 1 represent an error state and an initialization
   state, states,
   respectively. Values 2-6 define a representation for the
   SUPAPolicyAction. A value of 7 defines an ASCII string that
   contains the name of the SUPAPolicyAction to be executed (e.g., to
   be used in a regex search). A value of 8 defines the canonical
   representation, in ASCII, of an instance ID of this object.

5.3.2.6.2.  The Attribute "supaPolExecFailActionName[1..n]"

   This Their purpose is an optional array of string attributes that identifies the
   set of SUPAPolicyActions to take if support dynamically building a
   SUPAPolicyClause by enabling the SUPAPolicyStructure object
   that owns this association failed application to execute properly. The
   interpretation set the value of
   this string attribute is defined to a standard value.

   This list has been influenced by the
   supaPolExecFailTakeActionEncoding class attribute. The association
   defines the SUPAPolicyStructure that contains work in the set of policy
   actions to execute, I2NSF WG.
   Specifically, references [22] and [23] categorize selectors as
   exact-match, range-based, regular expressions, and custom match. In
   this attribute defines which of these
   actions categorization, the values in the above enumeration are to be executed. That there mapped
   as follows:

      o "Exact-match" is no need used to execute a
   SUPAPolicy, since the event and failure have already occurred.
   Note: [1..n] means that this is a multi-valued property that has
   at least one (and possibly more) attributes.

5.3.2.7. check for equality. The Aggregation "SUPAHasPolicyClause"

   This result is an optional aggregation
        unstructured unordered set. This includes values 6 and 7.
      o "Range-based" are **ordered** sets, where ranges that defines map to
        integers are used. This includes values 2-5, 8, 9, and 12.
      o "Regular expressions", which include the set use of
   SUPAPolicyClauses special
        characters that collectively define a search pattern. Two
        different syntaxes are aggregated by this particular
   SUPAPolicyStructure instance. The semantics of this
   aggregation specified; they are defined documented in [24]
        (for value 14) and [25]. This maps to values 13-15.

   Note that POSIX-based simple regular expressions (SRE) are
   **deprecated** by the SUPAHasPolicyClauseDetail
   association class.

   Every SUPAPolicyStructure object instance MUST aggregate at
   least one SUPAPolicyClause object instance. However, the
   converse is NOT true. POSIX-based basic regular expressions (BRE).

   Additional operators may be defined in future work. For example, a SUPAPolicyClause could be
   instantiated
   if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from
   include structured objects, then stored for later use in a policy repository.
   Furthermore, the same SUPAPolicyClause "deep" versions of operators
   1-6 could also be used by zero or
   more SUPAPolicyStructure object instances at a given time. Thus,
   the multiplicity of defined. In this aggregation is case, values 1-6 will be
   edited to explicitly indicate that they perform "shallow"
   comparison operations.

5.10.3.  SUPAPolicyOperator Relationships

   Currently, no relationships are defined as 0..1 on the
   aggregate (i.e., for the SUPAPolicyStructure side) and 1..n on SUPAPolicyOperator
   class (note that the
   part (i.e., decorator pattern obviates the SUPAPolicyClause side). This means that at
   least one SUPAPolicyClause MUST be aggregated by this
   SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may
   be aggregated by this particular SUPAPolicyStructure object.

5.3.2.8.  The Association Class "SUPAHasPolicyClauseDetail" need for
   relationships such as those in [6]). This is an optional abstract association class, because
   SUPAPolicyOperator, and defines its subclasses, inherit the
   SUPAHasDecoratedPolicyComponent aggregation, which was defined in
   section 5.7.3. Please refer to the examples in section 7, which
   show how to restrict the value, data type, range, and other
   semantics of the SUPAHasPolicyClause aggregation. The attributes
   and/or relationships of this association class can be SUPAPolicyOperator when used to
   determine which SUPAPolicyClauses are aggregated by which
   SUPAPolicyStructure objects.

   Attributes will be added to this class at in a later time.

5.4. SUPAPolicyClause.

5.11.  The Abstract Concrete Class "SUPAPolicyComponentStructure"

   This "SUPAPolicyValue"

   The SUPAPolicyValue class is a mandatory abstract concrete class that is the superclass of all
   objects that represent for
   modeling different types of components of values and constants that occur in a
   SUPAPolicy. Different types
   SUPAPolicyClause.

   SUPAPolicyValues are used to abstract the representation of policies have different types a
   SUPAPolicyRule from its implementation. Therefore, the design of
   structural components. This is accommodated by defining
   SUPAPolicyValues depends on two generic
   subclasses, called SUPAPolicyClause and SUPAPolicyComponentDecorator,
   which important factors.

   First, just as with SUPAPolicyVariables (see Section 5.9), some
   types of SUPAPolicyValues are common restricted in the values and/or the
   data type that they may be assigned. Second, there is a high
   likelihood that specific applications will need to different policy types. These two classes
   represent convenient control points for defining characteristics
   and behavior use their own
   variables that have specific meaning to a particular application.

   In general, there are common two ways to objects that serve as components apply constraints to an object
   instance of a SUPAPolicy. SUPAPolicyValue:

     1. use SUPAPolicyClauseComponentDecorator attributes to constrain
        just that individual object, and/or
     2. use the SUPAPolicyClauseHasDecoratorDetail association class
        attributes to constrain the relationship between the concrete
        subclass of SUPAPolicyClause defines a basic building block for writing
   parts and the concrete subclass of
        the SUPAPolicyVariable class

   The value of a SUPAPolicy. It SUPAPolicyValue is analogous typically compared to the value
   of a clause in a sentence.
   For example, in an ECA Policy Rule, SUPAPolicyVariable using the Event, Condition, and Action
   clauses are each made up type of at least one (subclass operator defined in
   a SUPAPolicyOperator. However, other objects may be used instead
   of a)
   SUPAPolicyClause. Similalry, declarative Policy Rules can also a SUPAPolicyVariable object, and other operators may be defined using (its own subclasses of) SUPAPolicyClauses. This class
   is
   in addition to those defined in section 5.5.

   SUPAPolicyComponentDecorator is used the SUPAPolicyOperator class.

   Please refer to implement the decorator
   pattern [11]. The decorator pattern enables all or part of one or
   more objects examples in section 7, which show how to "wrap" another concrete object. This enables
   restrict the
   definition of an extensible set value, data type, range, and other semantics of subclasses that can augment the
   definition of
   SUPAPolicyVariable when used in a SUPAPolicyClause.

5.11.1.  Problems with the RFC3460 Version of PolicyValue

   Please see Appendix A for a detailed comparison.

5.11.2.  SUPAPolicyValue Attributes

   Currently, SUPAPolicyValue defines two generic attributes, as
   described below.

5.11.2.1.  The Attribute "supaPolValContent[0..n]"

   This class is defined in
   section 5.7.

   Note a mandatory attribute that there are significant differences between the definition defines an array of strings.
   The array contains the SUPAPolicyComponentStructure class, and its attributes and
   relationships, and the definition value(s) of the corresponding class (and
   its attributes and relationships) in [5].

5.4.1.  SUPAPolicyComponentStructure Attributes

   No attributes are currently this SUPAPolicyValue object
   instance. Its data type is defined for by the
   SUPAPolicyComponentStructure class.

5.4.2.  SUPAPolicyComponentStructure Relationships

   SUPAPolicyComponentStructure participates in supaPolValEncoding
   class attribute. Note: [0..n] means that this is a single relationship,
   SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3.

5.5. multi-valued
   property that has zero or more attributes.

5.11.2.2.  The Abstract Class "SUPAPolicyClause" Attribute "supaPolValEncoding"

   This is a mandatory abstract class string attribute that separates contains the
   representation data type
   of a SUPAPolicy from its implementation.
   SUPAPolicyClause was abstracted from DEN-ng [2]. This abstraction
   is missing in [RFC3060], [RFC3460], [4], and [6]. This class the SUPAPolicyValue object instance. Its value is
   called PolicyStatement in [5], but defined by
   the supaPolValContent class attribute. Values include:

      0:  error
      1:  init
      2:  String
      3:  Integer
      4:  Boolean
      5:  Floating Point
      6:  DateTime
      7:  GUID
      8:  UUID
      9:  URI
     10:  DN
     11:  FQDN
     12:  FQPN
     13:  NULL

   Note that 0 and relationship
   definitions differ significantly from the corresponding designs
   in this document.

   A SUPAPolicy, regardless of its structure 1 represent error and semantics, can be
   abstracted into initialization states,
   respectively. A string is a set sequence of sentences. Each sentence can in turn be
   abstracted into zero or more characters. An
   Integer is a set of clauses. whole number, and has no fractional part. A SUPAPolicyClause is, Boolean may
   take the values TRUE and FALSE. A floating point number may contain
   fractional values, as its
   name implies, well as an exponent. A DateTime represents a clause (i.e.,
   value that has a part of date and/or a statement), and defines time component (as in the content Java or
   Python libraries). A NULL explicitly models the lack of a SUPAPolicy. The value.

5.11.3.  SUPAPolicyValue Relationships

   Currently, no relationships are defined for the SUPAPolicyValue
   class (note that the decorator pattern is used to
   enable an extensible set of objects to "wrap" the SUPAPolicyClause;
   this enables obviates the contents of a SUPAPolicyClause to be adjusted
   dynamically at runtime without affecting other objects.

   This document defines two different types of policy clauses:
   SUPAEncodedClause (which is generic, and can be used by any
   type of policy), and SUPABooleanClause (which is also generic,
   but is typically used by SUPAECAPolicyRule objects, since it is
   used specifically to represent Boolean clauses).

   SUPAPolicyClauses are objects need for
   relationships such as those in their own right, which
   facilitates their reuse. SUPAPolicyClauses can aggregate a set
   of any of [6]). SUPAPolicyValue, and its
   subclasses, inherit the subclasses of SUPAPolicyComponentDecorator, SUPAHasDecoratedPolicyComponent
   aggregation, which was shown defined in Figure 10. These four subclasses (i.e., SUPAPolicyTerm,
   SUPAGenericDecoratedComponent, SUPAECAComponent, and SUPACollection)
   provide four different ways section 5.7.3. Please refer to construct a SUPAPolicyClause:

     1) a SUPAPolicyClause can be made up of a set of three
        SUPAPolicyTerms,
   the examples in section 7, which enables constructing a {variable,
        operator, value} expression for building SUPAPolicyClauses
     2) a SUPAPolicyClause can be made up show how to restrict the value,
   data type, range, and other semantics of one or more
        SUPAEncodedClauses, which the SUPAPolicyValue when
   used in a SUPAPolicyClause.

5.12.  The Concrete Class "SUPAGenericDecoratedComponent"

   A SUPAGenericDecoratedComponent enables a SUPAPolicyClause to be
        formed as an encoded generic object (e.g., to pass YANG or CLI code)
     3) a SUPAPolicyClause can be made up of
   defined and used in a set of SUPACollections,
        which define SUPAPolicyClause. This class was derived
   from [2], but is not present in [RFC3460], [4], [5], or [6].

   This class should not be confused with the SUPAEncodedClause class.
   The SUPAGenericDecoratedComponent class represents a Collection (e.g., set, bad, associative arrays)
        of objects single, atomic
   object that can be assembled into SUPAPolicyClauses
     4) defines a SUPAPolicyClause can be made up **portion** of one or more
        SUPAECAComponents, which enables a SUPAPolicyClause to be
        formed using (reusable) Event, Condition, and/or Action
        objects

   SUPAPolicyClauses are aggregated by SUPAPolicyClause, whereas a SUPAPolicyStructure
   object, which enables all types of SUPAPolicies to uniformly be
   made up of one or more SUPAPolicyClauses.

5.5.1.  SUPAPolicyClause
   SUPAEncodedClause represents an **entire** SUPAPolicyClause.

5.12.1.  SUPAGenericDecoratedComponent Attributes

   Currently, SUPAGenericDecoratedComponent defines two generic
   attributes, as described below.

5.12.1.1. The Attribute "supaGenericDecoratedCompContent[0..n]"

   This section is a mandatory attribute that defines an array of strings.
   This array contains the attributes value(s) of the SUPAPolicyClause
   class, which
   SUPAGenericDecoratedComponent object instance that are inherited by all SUPAPolicyClause subclasses.

5.5.1.1. The Attribute "supaPolClauseDeployStatus"

   This used to
   construct a portion of a SUPAPolicyClause. Its data type is an optional enumerated, non-negative integer
   defined by the supaGenericDecoratedCompEncoding class attribute. The
   purpose of
   Note: [0..n] means that this attribute is to indicate a multi-valued property that this SUPAPolicyClause
   can has
   zero or cannot be deployed by the policy management system. more attributes.

5.12.1.2. The Attribute "supaGenericDecoratedCompEncoding"

   This is a mandatory integer attribute enables the policy manager to know which SUPAPolicyClauses
   to retrieve, and may be useful for the policy execution system for
   planning that defines the staging format of SUPAPolicies.
   the supaGenericDecoratedCompContent class attribute. Values include:

      0:  error
      1:  init
      2:  deployed and enabled  String
      3:  deployed and in test  Integer
      4:  deployed but not enabled  Boolean
      5:  ready to be deployed  Floating Point
      6:  cannot be deployed

   The values  DateTime
      7:  GUID
      8:  UUID
      9:  URI
     10:  DN
     11:  FQDN
     12:  FQPN
     13:  NULL

   Note that 0 and 1 represent an error state and an initialization
   state, states,
   respectively. If the value of this attribute A string is 0 a sequence of zero or 6, then
   the policy management system SHOULD ignore this SUPAPolicy.
   Otherwise, the policy management system MAY use this SUPAPolicyClause
   (once this SUPAPolicyClause more characters. An
   Integer is deployed a whole number, and enabled). However, has no fractional part. A Boolean may
   take the values TRUE and FALSE. A floating point number may contain
   fractional values, as well as an exponent. A DateTime 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 of 4 means a value.

5.12.2.  SUPAGenericDecoratedComponent Relationships

   Currently, no relationships are defiend for the
   SUPAGenericDecoratedComponent class (note that this policy is not admininstratively enabled the decorator
   pattern obviates the need for use and SHOULD NOT be used relationships such as those in OAM&P policies.

5.5.2.  SUPAPolicyClause Relationships

   SUPAPolicyClause [6]).
   SUPAGenericDecoratedComponent participates in a single relationship,
   SUPAHasPolicyClause,
   SUPAHasDecoratedPolicyComponent, as defined in section 5.3.2.7. Note that
   SUPAPolicyClause uses the decorator pattern to "wrap" this object
   with instances of the (concrete) subclasses of the
   SUPAPolicyComponentDecorator object.

5.6. 5.7.3.

5.13.  The Concrete Class "SUPAEncodedClause"

   This "SUPAPolicyCollection"

   A SUPAPolicyCollection is a mandatory an optional concrete class that refines the behavior enables
   a collection (e.g., set, bag, or other, more complex, collections
   of elements) of **arbitrary objects** to be defined and used as
   part of a SUPAPolicyClause. This class defines a generalized extension mechanism for
   representing SUPAPolicyClauses that have was derived from [2], but
   is not been modeled present in [RFC3460], [4], [5], or [6].

5.13.1.  Motivation

   One of the problems with other SUPAPolicy objects. Rather, ECA policy rules is when an enumeration
   occurs in the contents event and/or condition clauses.  For example, if a
   set of events is received, the policy
   clause are directly encoded into system may need to wait for
   patterns of events to emerge (e.g., any number of Events of type A,
   followed by either one event of type B or two events of type
   Event C). Similarly, for conditions, testing the value of a set of
   attributes may need to be performed. Both of these represent
   behavior similar to a set of if-then-else statements or a switch
   statement in imperative programming languages.

   It is typically not desirable for the
   SUPAEncodedClause. Hence, SUPAEncodedClause objects are reusable
   at the object level, whereas SUPABooleanClause policy system to represent
   each choice in such clauses are reusable
   at the individual Boolean expression level.

   This class uses two of as its attributes (supaEncodedClauseContent own policy clause (i.e., a
   3-tuple), as this creates object explosion and
   supaEncodedClauseEncoding) for defining poor performance.
   Furthermore, in these cases, it is often required to have a set of
   complex logic to be executed, where the logic varies according to
   the particular event or condition that was selected. It is much
   too complex to represent this using separate objects, especially
   when the content and type of
   encoding used in a given SUPAPolicyClause. The benefit of a
   SUPAEncodedClause logic is application- and/or vendor-specific. However,
   recall that it enables direct encoding of the text one of the SUPAPolicyClause, without having the "overhead" goals of using other
   objects. However, note that while this method is efficient, it
   does not reuse other SUPAPolicy objects. Furthermore, its potentially
   for reuse is reduced, as only SUPAPolicies that can use document was to facilitate
   the exact
   encoding machine-driven construction of policies. Therefore, a solution
   to this clause can reuse problem is needed.

5.13.2.  Solution

   Therefore, this object.

5.6.1.  SUPAEncodedClause Attributes

   This section document defines the attributes concept of the SUPAEncodedClause class.
   Prescriptive and/or descriptive information about the usage a collection of this
   SUPAEncodedClause may
   entities, called a SUPAPolicyCollection. Conceptually, the items
   to be provided by collected (e.g., events or conditions) are aggregated in
   one or more SUPAPolicyMetadata
   objects, which SUPAPolicyCollection objects of the appropriate type.
   Another optional SUPAPolicyCollection object could be used to
   aggregate logic blocks (including SUPAPolicies) to execute.
   Once finished, all appropriate SUPAPolicyCollection objects are each attached
   sent to an external system for evaluation.

   The computation(s) represented by the object instance SUPAPolicyCollection may be
   part of this
   SUPAEncodedClause.

5.6.1.1.  The Attribute "supaEncodedClauseContent"

   This a larger SUPAPolicyClause, since SUPAPolicyCollection is a mandatory string attribute, and defines the content
   subclass of
   this clause. It works with another class attribute, called
   supaEncodedClauseEncoding, which defines how SUPAPolicyComponentDecorator, and can be used to interpret
   decorate a SUPAPolicyClause. Therefore, the external system is
   responsible for providing a Boolean TRUE or FALSE return value, so
   that the policy system can use that value to represent the
   computation of this attribute (e.g., as the function(s) performed in the
   SUPAPolicyCollection in a Boolean clause.

5.13.3.  SUPAPolicyCollection Attributes

   Currently, SUPAGenericDecoratedComponent defines five attributes,
   as described below.

5.13.3.1.  The Attribute "supaPolCollectionContent[0..n]"

   This is an optional attribute that defines an array of strings.
   Each string or reference). These
   two attributes form a tuple, and together enable a machine to
   understand in the syntax and value array defines a domain-suitable identifier of this
   an object that is collected by this SUPAPolicyCollection instance.

5.6.1.2.
   Note: [0..n] means that this is a multi-valued property that has
   zero or more attributes.

5.13.3.2.  The Attribute "supaEncodedClauseEncoding" "supaPolCollectionEncoding"

   This is a mandatory non-negative enumerated integer attribute, and defines
   how to interpret the value of the supaEncodedClauseContent. It
   works with another class attribute (supaEncodedClauseContent),
   which that defines
   the content of the encoded clause. These two
   attributes form a tuple, and together enable a machine to
   understand the syntax and value format of the encoded clause for the
   object instance identifier of this class. This attribute is NOT required in all data model implementations. objects in this collection
   instance. Values include:

      0:  error (i.e., an error state)
      1:  init (i.e., an initialization state)
      2:  primary_key
      3:  foreign_key
      4:  GUID
      5:  UUID
      6:  URI
      7:  FQDN
      8:  FQPN
      9:  string_instance_id

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 2-8 define the content as a reference.
   The value 9 defines the canonical representation, in ASCII, of
   an instance ID of this object.

5.13.3.3.  The Attribute "supaPolCollectionFunction"

   This is an optional non-negative enumerated integer that defines
   the function of this collection instance. Values include:

      0:  error
      1:  init
      2:  event collection
      3:  condition collection
      4:  action collection
      5:  processing logic collection

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 2-4 define a collection of objects that are to
   be used to populate the event, condition, or action clauses,
   respectively, of a SUPAECAPolicyRule. A value of 5 indicates that
   this collection contains objects that define logic for processing
   a SUPAPolicy.

5.13.3.4.  The values 0 and 1 represent an error state and Attribute "supaPolCollectionIsOrdered"

   This is an initialization
   state, respectively. The value 9 defines optional Boolean attribute. If the canonical
   representation, in ASCII, value of an this
   attribute is TRUE, then all elements in this instance ID of this object.

5.6.1.3.
   SUPAPolicyCollection are ordered.

5.13.3.5.  The Attribute "supaEncodedClauseLanguage" "supaPolCollectionType"

   This is mandatory an optional non-negative enumerated integer attribute, and that defines
   the type of language used in collection that this encoded clause. instance is. Values include:

     0:  error
     1:  init
     2:  Text  set
     3:  YANG  bag (e.g., multi-set)
     4:  XML
      5:  TL1

   The values  dictionary (e.g., associative array)

   Note that 0 and 1 represent an error state and an initialization
   state, states,
   respectively.

5.6.1.4.  The Attribute "supaEncodedClauseResponse"

   This A set is an optional Boolean attribute that emulates a Boolean
   response unordered collection of this clause, so elements that MUST
   NOT have duplicates. A bag is an unordered collection of elements;
   it may be combined MAY have duplicates.  A dictionary is a table that associates a
   key with other
   subclasses a value.

   Sets have a number of important functions, including:

      o membership:   returns TRUE if the SUPAPolicyClause element being tested is
                      in the set, and FALSE otherwise
      o subset:       returns TRUE if all elements in the first set
                      are also in the second set
      o union:        returns all elements from both sets with no
                      duplicates
      o intersection: returns all elements that provide are in both sets
                      with no duplicates
      o difference:   returns all elements in the first set that
                      are not in the second set

   Bags have a status as to
   their correctness and/or evaluation state. This enables this
   object to be used number of important functions in addition to construct more complex Boolean clauses.
   Note the
   functions defined for sets (note that this attribute does while the above set of
   functions for a set and a bag are the same, a bag is a different
   data type than a set):

      o multiplicity:  returns the number of occurrences of an
                       element in the bag

      o count:         returns the number of all items, including
                       duplicates
      o countDistinct: returns the number of items, where all
                       duplicates are ignored

   A dictionary is an unordered set of key:value pairs, where each
   key is unique within a given dictionary. The combination of a
   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
   by a second element (the value). Each item in a set of items is
   separated by a comma. Keys MUST NOT have to be implemented by all
   data model implementations (e.g., [15]).

5.6.2.  SUPAEncodedClause NULL; values MAY be NULL.

   An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}.
   An example of a null dictionary is simply {}.

5.13.4.  SUPAPolicyCollection Relationships

   SUPAPolicyClause

   Currently, no relationships are defined for the
   SUPAGenericDecoratedComponent class (note that the decorator
   pattern obviates the need for relationships such as those in [6]).
   SUPAPolicyCollection participates in a single inherited relationship,
   SUPAHasPolicyClause,
   SUPAHasDecoratedPolicyComponent, as defined in section 5.3.2.7.

5.7. 5.7.3.

5.14.  The Abstract Class "SUPAPolicyComponentDecorator"

   This is a mandatory an optional class, and is used to implement represents how the decorator
   pattern. The decorator pattern enables all or part of one or more
   objects
   can be applied to "wrap" another concrete object. This means objects that any
   any concrete subclass of SUPAPolicyClause decorate another object. This is wrapped by any
   concrete subclass of SUPAPolicyComponentDecorator, as
   shown in Figure 19 25 below.

     A
             +------------------------------+
    +--------------+---------------------+
    |                                    |/
    | 1..n SUPAPolicyClauseComponentDecorator +------------+
    | SUPAPolicyComponentStructure +--------+                                    |\           |
    +----------+-------------------------+ 0..n       |
                                                      | used to wrap
             +------------------------------+
                      SUPAHasDecoratedPolicyComponent | concrete
                               / \
                    +---------------------------------+
                    ^                                 | subclasses of
                                I
                    | PolicyClause
                                I                                 |
                +---------------+--------------+
     C              |                                 |
    +---------------+---------------------+           |
    |SUPAHasDecoratedPolicyComponentDetail|          / \
                I                              I
    +---------------+---------------------+           A
                                       A         I                 A            I             \ / 0..1
     +----------+---------+     +--------------+-----+---------+
     |  SUPAPolicyClause  |
                                      +---------------+--------------+
                                      | SUPAPolicyComponentDecorator |
     +----------+---------+     +--------------+---------------+
                I                              I
                I                              I
               / \                            / \
         Concrete Subclasses,          Concrete Subclasses
      (e.g., SUPAEncodedClause)      (e.g., SUPAPolicyEvent)
       (object being wrapped)         (wrapping object(s))
                                      +------------------------------+

      Figure 19.  The PolicyComponent Decorator Pattern

5.7.1.  The Decorator Pattern

   Each SUPAPolicyComponentDecorator object HAS_A (i.e., wraps) a
   concrete instance of the SUPAPolicyClause object. This means that
   the SUPAPolicyComponentDecorator object has an instance variable 25.  Decorating Objects that holds a reference to Decorate Another Object

   Figure 25 realizes a SUPAPolicyClause object. Since the
   SUPAPolicyComponentDecorator object has the same interface as the
   SUPAPolicyClause object, the SUPAPolicyComponentDecorator object
   (and all of its subclasses) are transparent to clients of the
   SUPAPolicyClause object (and its subclasses). This means recursive decorator pattern, in that
   SUPAPolicyComponentDecorator object instances can add attributes
   and/or methods to those of the any
   concrete instance of the chosen subclass of SUPAPolicyClause.

   Figure 20 shows how this is done for methods.
     - Figure 20a shows the initial object to SUPAPolicyClauseComponentDecorator can be wrapped
     - Figure 20b shows the SUPAPolicyEvent object wrapping the
       SUPAEncodedClause object
     - Figure 20c shows SUPAGenericDecoratedComponent object
       wrapping the SUPAPolicyEvent object.

      +-------------------+
      | SUPAEncodedClause |
      |   eval()          |
      +-------------------+
     (a)  Initial Object

          ===>
                 +------------------------+
                 |  SUPAPolicyEvent       |
                 |    eval()              |
                 | +-------------------+  |
                 | | SUPAEncodedClause |  |
                 | |     eval()        |  |
                 | +-------------------+  |
                 +------------------------+
     (b)  SUPAPolicyEvent "wraps" SUPAEncodedClause

                    ===>
                            +--------------------------------+
                            |  SUPAGenericDecoratedComponent |
                            |    eval()                      |
                            |   +-----------------------+    |
                            |   | SUPAPolicyEvent       |    |
                            |   |   eval()              |    |
                            |   | +-------------------+ |    |
                            |   | | SUPAEncodedClause | |    |
                            |   | |    eval()         | |    |
                            |   | +-------------------+ |    |
                            |   +-----------------------+    |
                            +--------------------------------+
     (c)  SUPAGenericDecoratedComponent "wraps" SUPAPolicyEvent

       Figure 20.  Conceptual Depiction
   decorated by any concrete subclass of eval() Decorated Method

   When the eval() method is called in the outermost object
   (SUPAGenericDecoratedComponent), it delegates to the eval() method SUPAPolicyComponentDecorator.

   The SUPAHasPolicyClause aggregation enables one or more concrete
   subclasses of SUPAPolicyEvent, which in turn delegates SUPAPolicyClauseComponentDecorator to the eval() method wrap a concrete
   subclass of SUPAEncodedClause. This method executes and returns the
   results to SUPAPolicyEvent, which executes and returns the results
   to SUPAGenericDecoratedComponent, which executes and returns SUPAPolicyClause. Its semantics are defined by the
   final result.

5.7.2.
   SUPAPolicyClauseHasDecoratorDetail association class.

5.14.1.  SUPAPolicyComponentDecorator Attributes

   Currently, there are two attributes defined for this class, which
   are described in the following subsections. Both attributes are
   used by subclasses to constrain **constrain the behavior of that subclass; subclass**;
   they do **not** affect the relationship between the concrete
   subclass of SUPAPolicyComponentDecorator that is wrapping
   the concrete subclass of SUPAPolicyClause. SUPAPolicyClauseComponentDecorator.

   This is different than the use of similar attributes defined in
   the SUPAHasDecoratedPolicyComponentDetail association class (which class. The
   attributes of SUPAPolicyComponentDecorator are used to constrain
   the relationship between (concrete subclass of) the SUPAPolicyClauseComponentDecorator
   that is being wrapped. In contrast, the attributes of
   SUPAHasDecoratedPolicyComponentDetail are used to define which
   concrete
   subclass subclasses of SUPAPolicyClause and the SUPAPolicyClauseComponentDecorator can be
   wrapped by which concrete subclass subclasses of the
   SUPAPolicyComponentDecorator object that is wrapping it).
   Note that [2] does not define any attributes for this class.

5.7.2.1.

5.14.1.1.  The Attribute "supaPolCompConstraintEncoding"

   This is a mandatory non-negative enumerated integer that defines
   how to interpret each string in the supaPolCompConstraint class
   attribute. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text

   Enumerations 1 0 and 2 1 signify an error state and an initialization
   state, respectively. Enumeraitons 3-5 Enumerations 2-4 are dedicated to OCL (with
   OCL 2.4 being the latest version as of this writing). QVT defines a
   set of languages [20] (the two most powerful and useful are defined
   by enumerations 5 and 6). Alloy is a language for describing
   constraints, and uses a SAT solver to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but is included for completeness.

   If this class is instantiated, then this attribute SHOULD also be
   instantiated, and SHOULD be part of a conformant implementation.

5.7.2.2.

5.14.1.2.  The Attribute "supaPolCompConstraint[0..n]"

   This is a mandatory array of string attributes. Each attribute
   specifies a constraint to be applied using the encoding defined in
   the supaPolCompConstraintEncoding class attribute. This provides
   a more rigorous and flexible treatment of constraints than is
   possible in [RFC3460], [4], [5], and [6]. Note: [0..n] means that
   this is a multi-valued property that may have zero or
   more attributes.

5.7.3.

5.14.2.  SUPAPolicyComponentDecorator Relationships

   One

   A single relationship is currently defined for this class, the
   SUPAPolicyComponentDecorator, which is described in the following subsection.

5.7.3.1. below.

5.14.2.1  The Aggregation "SUPAHasDecoratedPolicyComponent"

   This is a mandatory aggregation, and is part of a recursive
   decorator pattern. It is used to enable a concrete instance of a
   SUPAPolicyComponentDecorator to dynamically add behavior to a
   specific type (of concrete subclass) of SUPAPolicyClause a
   SUPAPolicyClauseComponentDecorator object. The semantics of this
   aggregation are defined by the SUPAHasDecoratedPolicyComponentDetail
   association class.

5.7.3.2.

5.14.2.2.  The Association Class
           "SUPAHasDecoratedPolicyComponentDetail"

   This is a mandatory concrete association class, and defines the
   semantics of the SUPAHasDecoratedPolicyComponent aggregation. The
   purpose of this class is to use the Decorator pattern to determine
   which concrete subclasses of the SUPAPolicyComponentDecorator object instances, class,
   if any, are required to augment the functionality of the concrete
   subclass of
   SUPAPolicyClause SUPAPolicyClauseComponentDecorator that is being used.

   Currently, there are two attributes defined for this class, which
   are described in the following subsections. Both attributes are
   used in this association class to constrain the **relationship**
   between the concrete subclass of SUPAPolicyComponentDecorator that
   is wrapping the concrete subclass of SUPAPolicyClause. Note that
   class attributes of SUPAPolicyComponentDecorator (see section
   5.9.2) only affect that specific subclass.

5.7.3.2.1. the
   SUPAPolicyClauseComponentDecorator class.

5.14.2.1.1.  The Attribute "supaDecoratedConstraintEncoding" "supaPolCompConstraintEncoding"

   This is a mandatory non-negative enumerated integer that defines
   how to interpret each string in the supaDecoratedConstraint class
   attribute. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text

   Enumerations 1 0 and 2 1 signify an error state and an initialization
   state, respectively. Enumeraitons 3-5 Enumerations 2-4 are dedicated to OCL (with
   OCL 2.4 being the latest version as of this writing). QVT defines a
   set of languages [20] (the two most powerful and useful are defined
   by enumerations 5 and 6). Alloy is a language for describing
   constraints, and uses a SAT solver to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but is included for completeness.
   If this class is instantiated, then this attribute SHOULD also be
   instantiated, and SHOULD be part of a conformant implementation.

5.7.3.2.2.

5.14.2.1.2.  The Attribute "supaDecoratedConstraint[0..n]" "supaPolCompConstraint[0..n]"

   This is a mandatory array of string attributes. Its purpose is to
   collect a set of constraints to be applied to a decorated object.
   The interpretation of each constraint in the array is defined in
   the supaDecoratedConstraintsEncoding class attribute.
   Note: [0..n] means that this is a multi-valued property that may
   have zero or more attributes.

5.7.4.  Illustration of Constraints in the Decorator Pattern

   Figure 21 builds a simple SUPAPolicyClause that has both types
   of relationships, and illustrates how the different constraints
   defined in sections 5.7.2 (class attribute constraints) and section
   5.7.3 (relationship constraints) can be used.

    A                                   A
   +------------------+           0..1 +----------------------------+
   |                  | 1..n        / \|                            |
   | SUPAPolicyClause +------+-----  A +SUPAPolicyComponentDecorator|
   |                  |      ^      \ /|                            |
   +---------+--------+      |         +-----------+----------------+
             I               |                     I
             I               |                     I
     C       I               |            C        I
    +--------+--------+      |           +---------+---------+
    |SUPAEncodedClause|      |           |  SUPAPolicyEvent  |
    +-----------------+      |           +-------------------+
                             |
            C                |
           +-----------------+-------------------+
           |SUPAHasDecoratedPolicyComponentDetail|
           +-------------------------------------+

          Figure 21.  Constraints in the Decorator Pattern

   Figure 21 says that a SUPAPolicyClause, realized as a
   SUPAEncodedClause, is wrapped by a SUPAPolicyEvent object. The
   attributes in the SUPAPolicyComponentDecorator object are used
   to constrain the attributes in the SUPAPolicyEvent object, while
   the attributes in the SUPAHasDecoratedPolicyComponentDetail
   object are used to contrain the behavior of the aggregation
   (SUPAHasDecoratedPolicyComponent).  For example, the attributes in
   the SUPAPolicyComponentDecorator object could restrict the data
   type and range of the components in the SUPAPolicyEvent, while
   the attributes in the SUPAHasDecoratedPolicyComponentDetail object
   could restrict which SUPAPolicyEvent objects are allowed to be
   used with which SUPAEncodedClauses.

5.8.

5.15.  The Abstract Concrete Class "SUPAPolicyTerm" "SUPAPolicySource"

   This is a mandatory abstract an optional class that is the parent of
   SUPAPolicy objects that can be used to define defines a standard way to
   test or set the value of a variable. It does this by defining a
   3-tuple, in the form {variable, operator, value}, where each
   element of the 3-tuple is defined by a concrete subclass of the
   appropriate type (i.e., SUPAPolicyVariable, SUPAPolicyOperator,
   and SUPAPolicyValue classes, respectively). For example, a
   generic test managed entities
   that authored, or set of the value of a variable is expressed as:

      {variable, operator, value}.

   For event and condition clauses, are otherwise responsible for, this is typically as written above
   (e.g., does variable = value); for action clauses, it is typically
   written as <operator> <variable> <value> (e.g., SET var to 1). A
   class diagram is shown in Figure 22.

                         A
                        +----------------+
                        | SUPAPolicyTerm |
                        +--------+-------+
                                / \
                                 I
                                 I
                                 I
               +-----------------+---+--------------------+
               I                     I                    I
               I                     I                    I
       C       I             C       I             C      I
      +--------+---------+  +--------+---------+  +-------+-------+
      |SUPAPolicyVariable|  |SUPAPolicyOperator|  |SUPAPolicyValue|
      +------------------+  +------------------+  +---------------+

            Figure 22.  SUPAPolicyTerm Class Hierarchy
   SUPAPolicyRule. Note that generic test and set expressions do not have to only use
   objects that are subclasses of SUPAPolicyTerm. For example, the
   polVendorDecoratedContent attribute of the
   SUPAGenericDecoratedComponent could be used as the variable (or the
   value) term of a get or set expression.

   Hence, the utility of the subclasses of SUPAPolicyTerm is in the
   ability of its subclasses to define a generic framework for
   implementing get and set expressions. This is in contrast to
   previous designs (e.g., [RFC3460] and [6]), which depended on
   defining a broad set of subclasses of PolicyVariable and
   PolicyValue. (Note that [4] SUPAPolicySource does not have this generic capability).

5.8.1.  SUPAPolicyTerm Attributes

   Currently, SUPAPolicyTerm defines a single attribute, as described
   in the following subsection. Constraints on the subclasses of
   SUPAPolicyTerm can be applied in two different ways:

     1. use SUPAPolicyComponentDecorator attributes to constrain
        just that individual subclass, and/or
     2. use SUPAHasDecoratedPolicyComponentDetail association class
        attributes to constrain the relationship between the concrete
        subclass of SUPAPolicyClause NOT
   evaluate or execute SUPAPolicies. Its primary use is for
   auditability and the concrete subclass implementation of
        the SUPAPolicyTerm deontic and/or alethic logic.
   A class

5.8.1.1.  The Attribute "supaPolTermIsNegated"

   This diagram is shown in Figure 15.

   A SUPAPolicySource SHOULD be mapped to a mandatory Boolean attribute. If the value role or set of this
   attribute is true, then this particular SUPAPolicyTerm subclass
   (which represents roles
   (e.g., using the role-object pattern [11]). This enables
   role-based access control to be used to restrict which entities
   can author a term) is negated; otherwise, it given policy. Note that Role is not.

5.8.2.  SUPAPolicyTerm Relationships a type of
   SUPAPolicyMetadata.

5.15.1.  SUPAPolicySource Attributes

   Currently, no dedicated relationships attributes are defined for the
   SUPAPolicyTerm class (as there are this class.

5.15.2.  SUPAPolicySource Relationships

   SUPAPolicySource participates in [RFC3460] and [6]) that
   aggregate policy variable and policy value objects into a policy
   rule). This is:

     1) to enable the subclasses of SUPAPolicyTerm to be used by
        other SUPAPolicyComponentDecorator objects, and
     2) because the decorator pattern replaces how such relationships
        were used single relationship,
   SUPAHasPolicySource, as defined in [RFC3460] and [6].

   SUPAPolicyTerm, section 5.3.2.1.
   SUPAPolicySource, and its subclasses, inherit the
   SUPAHasDecoratedPolicyComponent
   SUPAHasPolicyMetadata aggregation, which was is
   defined in section 5.7.3.

5.9. 5.17.2.1.

5.16.  The Concrete Class "SUPAPolicyVariable" "SUPAPolicyTarget"

   This is a mandatory concrete an optional class that defines information that
   forms a part set of a SUPAPolicyClause. It specifies a concept or
   attribute managed entities
   that represents a variable, which should be compared to a value, as specifed in this SUPAPolicyClause. If it SUPAPolicy is used in applied to. Figure 15 shows a SUPAECAPolicyRule, then its value MAY be able to be changed at
   any time, including run-time, via use class diagram
   of the decorator pattern.
   This is not possible SUPAPolicyTarget.

   A managed object must satisfy two conditions in previous designs ([RFC3460, [4], and [6]).

   The value of a SUPAPolicyVariable is typically compared order to the
   value of a SUPAPolicyValue using the type of operator be defined in
   as a SUPAPolicyOperator. However, other objects may be used instead SUPAPolicyTarget. First, the set of a SUPAPolicyValue object, and other operators may be defined
   in addition managed entities that are
   to those defined in be affected by the SUPAPolicyOperator class.

   SUPAPolicyVariables are used SUPAPolicy must all agree to abstract play the representation role of
   a
   SUPAPolicyRule from its implementation. Some SUPAPolicyVariables
   are restricted in the values and/or the data type that they SUPAPolicyTarget. In general, a managed entity may
   be assigned. For example, port numbers cannot be negative, and
   they cannot be floating-point numbers. These and other constraints or may not be defined
   in two different ways:

     1. use SUPAPolicyComponentDecorator attributes to constrain
        just a state that individual subclass, and/or
     2. use SUPAHasDecoratedPolicyComponentDetail association class
        attributes enables SUPAPolicies to constrain the relationship between the concrete
        subclass of SUPAPolicyClause and the concrete subclass of
        the SUPAPolicyVariable class

   Please refer be applied to the examples in section 7, which show how it to
   restrict the value, data type, range, and other semantics of the
   SUPAPolicyVariable when used in change
   its state; hence, a SUPAPolicyClause.

5.9.1.  Problems with negotiation process may need to occur to enable
   the RFC3460 Version of PolicyValue

   Please see Appendix A for a detailed comparison.

5.9.2.  SUPAPolicyVariable Attributes

   SUPAPolicyVariable defines one attribute, as described below.

5.9.2.1.  The Attribute "supaPolVarName"

   This SUPAPolicyTarget to signal when it is an optional string attribute that contains willing to have
   SUPAPolicies applied to it. Second, a SUPAPolicyTarget must be able
   to process (directly or with the name aid of
   this SUPAPolicyVariable. This variable name forms part a proxy) SUPAPolicies.

   If a proposed SUPAPolicyTarget meets both of the
   {variable, operator, value} canonical form these conditions, it
   SHOULD set its supaPolicyTargetEnabled Boolean attribute to a
   value of TRUE.

   A SUPAPolicyTarget SHOULD be mapped to a SUPAPolicyClause.

5.9.3.  SUPAPolicyVariable Relationships role (e.g., using the
   role-object pattern). This enables role-based access control to
   be used to restrict which entities can author a given policy.
   Note that Role is a type of SUPAPolicyMetadata.

5.16.1.  SUPAPolicyTarget Attributes

   Currently, no relationships attributes are defined for the SUPAPolicyVariable
   class (note that the decorator pattern obviates the need for
   relationships such SUPAPolicyTarget
   class.

5.16.2.  SUPAPolicyTarget Relationships

   SUPAPolicyTarget participates in a single relationship,
   SUPAHasPolicyTarget, as those defined in [RFC3460] and [6]). This is
   because SUPAPolicyVariable, and its subclasses, inherit section 5.3.2.3. It also inherits
   the
   SUPAHasDecoratedPolicyComponent aggregation, which was defined in SUPAHasPolicyMetadata aggregation (see section 5.7.3.

5.10. 5.17.2.1.).

5.17.  The Concrete Abstract Class "SUPAPolicyOperator"

   This "SUPAPolicyMetadata"

   Metadata is a mandatory concrete class for modeling different types information that describes and/or prescribes
   characteristics and behavior of
   operators another object that are used in a SUPAPolicyClause.

   The restriction is **not**
   an inherent, distinguishing characteristic or behavior of the type that
   object (otherwise, it would be an integral part of operator used in a SUPAPolicyClause
   restricts the semantics that can object).

   For example, a socialSecurityNumber attribute should not be expressed part
   of a generic Person class. First, most countries in that
   SUPAPolicyClause. It the world do
   not know what a social security number is, much less use them.
   Second, a person is typically used not created with SUPAPolicyVariables
   and SUPAPolicyValue a social security number;
   rather, a social security number is used to form track people for
   administering social benefits, though it is also used as a SUPAPolicyClause.

5.10.1.  Problems with form
   of identification.

   Continuing the RFC3460 Version

   Please see Appendix A for example, a detailed comparison.

5.10.2.  SUPAPolicyOperator Attributes

   Currently, SUPAPolicyOperator defines better way to add this capability to a
   model would be to have a single generic attribute, Identification class, then
   define a SocialSecurityNumber subclass, populate it as described below.

5.10.2.1.  The Attribute "supaPolOpType"

   This necessary,
   and then define a composition between a Person and it (this is a mandatory non-negative enumerated integer that specifies
   the various types of operators that
   composition because social security numbers are allowed not reused).

   Since social security numbers are given to be US citizens, permanent
   residents, and temporary working residents, and because it is
   also used in this
   particular SUPAPolicyClause. Values include:

     0:  error
     1:  init
     2:  Greater than
     3:  Greater than or equal to
     4:  Less than
     5:  Less than or equal to
     6:  Equal to
     7:  Not equal administer benefits, the composition is realized
   as an association class to
     8:  IN
     9:  NOT IN
    10:  SET
    11:  CLEAR (0 for integers, "" define how it is being used.

   An example of descriptive metadata for strings, FALSE network elements would be
   documentation about best current usage practices (this could also
   be in the form of a reference). An example of prescriptive
   metadata for Booleans)
    12:  BETWEEN (inclusive)

   Note that 0 and 1 represent error and initialization states,
   respectively. Their purpose is to support dynamically building network elements would be the definition of a
   SUPAPolicyClause by enabling time
   period during which specific types of operations are allowable.

   This is an optional class that defines the application top of a hierarchy of
   model elements that are used to set the value define different types of
   this attribute metadata
   that can be applied to policy and policy component objects. This
   enables common metadata to a standard value.

   Additional operators may be defined in future work. For example,
   if SUPAPolicyVariables as objects and SUPAPolicyValues are expanded to/from
   include structured objects, then "deep" versions of operators
   1-6 could also be defined. In this case, values 1-6 will be
   edited reused
   when the metadata are applicable. One way to explicitly indicate that they perform "shallow"
   comparison operations.

5.10.3.  SUPAPolicyOperator Relationships

   Currently, no relationships control whether
   SUPAPolicyMetadata objects are defined for the SUPAPolicyOperator
   class (note that reused is by using the decorator pattern obviates attributes
   of the need for
   relationships such as those in [6]). This SUPAHasPolicyMetadataDetail association class.

   It is because
   SUPAPolicyOperator, and recommended that this class, along with its
   SUPAPolicyConcreteMetadata and SUPAPolicyMetadataDecorator
   subclasses, inherit the
   SUPAHasDecoratedPolicyComponent aggregation, which was be used as part of a conformant implementation. It is
   defined in
   section 5.7.3. Please refer to the examples in section 7, which
   show how be optional, since metadata is not strictly required.
   However, metadata can help specify and describe SUPAPolicyObject
   entities, and can also be used to restrict drive dynamic behavior.

5.17.1.  SUPAPolicyMetadata Attributes

   This section defines the value, data type, range, and other
   semantics attributes of the SUPAPolicyOperator when used in a SUPAPolicyClause.

5.11. SUPAPolicyMetadata
   class.

5.17.1.1.  The Concrete Class "SUPAPolicyValue" Attribute "supaPolMetadataDescription"

   This is an optional string attribute that defines a free-form
   textual description of this metadata object.

5.17.1.2.  The SUPAPolicyValue class Attribute "supaPolMetadataIDContent"

   This is a mandatory concrete class for
   modeling different types of values and constants string attribute that occur in a
   SUPAPolicyClause.

   SUPAPolicyValues are used to abstract the representation represents part of a
   SUPAPolicyRule from its implementation. Therefore, the design
   object identifier of
   SUPAPolicyValues depends on two important factors. First, just as
   with SUPAPolicyVariables (see Section 5.11), some types an instance of
   SUPAPolicyValues are restricted in this class. It defines the values and/or
   content of the data
   type that they may be assigned. Second, there is a high likelihood
   that specific applications will need to use their own variables
   that have specific meaning object identifier. It works with another class
   attribute, called supaPolMetadataIDEncoding, which defines how to a particular application.

   In general, there are
   interpret this attribute. These two ways to apply constraints attributes form a tuple,
   and together enable a machine to understand the syntax and value
   of an object identifier for the object instance of a SUPAPolicyValue:

     1. use SUPAPolicyComponentDecorator attributes to constrain
        just this class.

5.17.1.3.  The Attribute "supaPolMetadataIDEncoding"

   This is an optional non-zero enumerated integer attribute that individual subclass, and/or
     2. use SUPAHasDecoratedPolicyComponentDetail association
   represents part of the object identifier of an instance of this
   class. It defines the format of the object identifier. It works
   with another class attribute, called supaPolMetadataIDContent,
   which defines the content of the object ID.

   These two attributes form a tuple, and together enable a machine
   to constrain understand the relationship between syntax and value of an object identifier for
   the concrete
        subclass object instance of SUPAPolicyClause this class. The supaPolMetadataIDEncoding
   attribute is mapped to the following values:

      0:  error (i.e., an error state)
      1:  init (i.e., an initialization state)
      2:  primary_key
      3:  foreign_key
      4:  GUID
      5:  UUID
      6:  URI
      7:  FQDN
      8:  FQPN
      9:  string_instance_id

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 2-8 define the concrete subclass of content as a reference. Value 9
   defines the SUPAPolicyValue class

   The value of content as a SUPAPolicyValue string that is typically compared to the value canonical
   representation, in ASCII, of a SUPAPolicyVariable using an instance ID of this object.

5.17.1.4.  The Attribute "supaPolMetadataName"

   This is an optional string attribute that defines the type name of operator defined this
   SUPAPolicyMetadata object.

5.17.2.  SUPAPolicyMetadata Relationships

   SUPAPolicyMetadata participates in
   a SUPAPolicyOperator. However, other objects may be used instead
   of a SUPAPolicyVariable object, and other operators may be two aggregations. The first,
   SUPAHasPolicyMetadata, which is defined in addition to those the following subsection.
   The second, SUPAHasMetadataDecorator, is defined in the SUPAPolicyOperator class.

5.11.1.  Problems with the RFC3460 Version of PolicyValue

   Please see Appendix A for a detailed comparison.

5.11.2.  SUPAPolicyValue Attributes

   Currently, SUPAPolicyValue defines two generic attributes, as
   described below.

5.11.2.1. section 5.19.2.

5.17.2.1.  The Attribute "supaPolValContent[0..n]" Aggregation "SUPAHasPolicyMetadata"

   This is a mandatory attribute aggregation that defines an array the set of strings.
   SUPAPolicyMetadata that are aggregated by this particular
   SUPAPolicyObject.

   The array contains the value(s) multiplicity of this SUPAPolicyValue object
   instance. Its data type relationship is defined by as 0..n on the supaPolValEncoding
   class attribute.
   Note: [0..n]
   aggregate (SUPAPolicyObject) side, and 0..n on the part
   (SUPAPolicyMetadata) side. This means that this relationship is
   optional. However, it is recommended that this aggregation be used
   as part of a multi-valued property conformant implementation, because it enables metadata
   to be attached to all objects that has
   zero or more attributes.

5.11.2.2. inherit from the SUPAPolicyObject
   class. The Attribute "supaPolValEncoding" semantics of this aggregation are implemented using the
   SUPAHasPolicyMetadataDetail association class.

5.17.2.2.  The Abstract Class "SUPAHasPolicyMetadataDetail"

   This is a mandatory string attribute that contains concrete association class, and defines the data type
   semantics of the SUPAPolicyValue object instance. SUPAHasPolicyMetadata aggregation. Its value purpose is defined
   to determine which SUPAPolicyMetadata object instances should be
   attached to which particular object instances of the
   SUPAPolicyObject class. This is done by using the supaPolValContent attributes and
   relationships of the SUPAPolicyMetadataDetail class to constrain
   which SUPAPolicyMetadata objects can be aggregated by which
   particular SUPAPolicyObject instances.

5.17.2.2.1.  The Attribute "supaPolMetadataConstraintEncoding"

   This is an optional non-negative enumerated integer that defines
   how to interpret each string in the supaPolMetadataConstraint
   class attribute. Values include:

     0:  error
     1:  init
     2:  String  OCL 2.4
     3:  Integer  OCL 2.x
     4:  Boolean  OCL 1.x
     5:  Floating Point  QVT 1.2 - Relations Language
     6:  DateTime  QVT 1.2 - Operational language
     7:  GUID  Alloy
     8:  UUID
      9:  URI
     10:  DN
     11:  FQDN
     12:  FQPN
     13:  NULL

   Note that  ASCII Text

   Enumerations 0 and 1 represent signify an error state and an initialization states,
   state, respectively. A string is a sequence of zero or more characters. An
   Integer is a whole number, and has no fractional part. A Boolean may
   take the values TRUE and FALSE. A floating point number may contain
   fractional values, as well as an exponent. A DateTime 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 of a value.

5.11.3.  SUPAPolicyValue Relationships

   Currently, no relationships Enumerations 2-4 are defined for the SUPAPolicyValue
   class (note that the decorator pattern obviates the need for
   relationships such as those in [6]). SUPAPolicyValue, and its
   subclasses, inherit the SUPAHasDecoratedPolicyComponent
   aggregation, which was defined in section 5.7.3. Please refer to
   the examples in section 7, which show how dedicated to restrict OCL (with
   OCL 2.4 being the value,
   data type, range, and other semantics latest version as of the SUPAPolicyValue when
   used in a SUPAPolicyClause.

5.12.  The Concrete Class "SUPAGenericDecoratedComponent"

   A SUPAGenericDecoratedComponent enables this writing). QVT defines a generic object to be
   set of languages [20] (the two most powerful and useful are defined
   by enumerations 5 and used in 6). Alloy is a SUPAPolicyClause. This class was derived
   from [2], but language for describing
   constraints, and uses a SAT solver to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not present in [RFC3460], [4], [5], or [6].

   This class should recommended (since it is informal,
   and hence, not be confused with the SUPAEncodedClause class.
   The SUPAGenericDecoratedComponent verifiable), but is included for completeness.

   If this class represents a single, atomic
   object that defines a **portion** is instantiated, then this attribute SHOULD also be
   instantiated, and SHOULD be part of a SUPAPolicyClause, whereas a
   SUPAEncodedClause represents an **entire** SUPAPolicyClause.

5.12.1.  SUPAGenericDecoratedComponent Attributes

   Currently, SUPAGenericDecoratedComponent defines two generic
   attributes, as described below.

5.12.1.1. conformant implementation.

5.17.2.2.2.  The Attribute "supaVendorDecoratedCompContent[0..n]" "supaPolMetadataConstraint[0..n]"

   This is a mandatory attribute that defines an optional array of strings.
   This array contains the value(s) of string attributes. Each attribute
   specifies a constraint to be applied using the
   SUPAGenericDecoratedComponent object instance. Its data type is
   defined format identified
   by the supaVendorDecoratedEncoding value of the supaPolMetadataPolicyConstraintEncoding class
   attribute. This provides a more rigorous and flexible treatment of
   constraints than is possible in [RFC3460].

   If this class is instantiated, then this attribute SHOULD also be
   instantiated, and should be part of a conformant implementation.
   Note: [0..n] means that this is a multi-valued property that has
   zero or more attributes.

5.12.1.2.

5.17.2.2.3.  The Attribute "supaVendorDecoratedCompEncoding" "supaPolMetadataIsApplicable"

   This is a mandatory integer attribute that defines an optional Boolean attribute. If the format value of
   the supaVendorDecoratedContent class attribute. Values include:

      0:  undefined
      1:  String
      2:  Integer
      3:  Boolean
      4:  Floating Point
      5:  DateTime
      6:  GUID
      7:  UUID
      8:  URI
      9:  FQDN
     10:  FQPN
     11:  NULL

   Note that 0 and 1 represent error and initialization states,
   respectively. A string this
   attribute is a sequence TRUE, then the SUPAPolicyMetadata object(s) of zero or more characters. An
   Integer this
   particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated
   by this particular SUPAPolicyObject.

5.18.  The Concrete Class "SUPAPolicyConcreteMetadata"

   This is a whole number (e.g., it has no fractional part). A
   Boolean represents an optional concrete class. It defines an object that will
   be wrapped by concrete instances of the values TRUE and FALSE. A floating point
   number may contain fractional values, as well SUPAPolicyMetadataDecorator
   class. It can be viewed as an exponent. A
   DateTime represents a value "carrier" for metadata that has a date and/or will be
   attached to a time component
   (as in subclass of SUPAPolicyObject. Since the Java or Python libraries). A NULL explicitly models decorator
   pattern is used, any number of concrete subclasses of the
   lack
   SUPAPolicyMetadataDecorator class can wrap an instance of the
   SUPAPolicyConcreteMetadata class.

   It is recommended that this class be used as part of a value.

5.12.2.  SUPAGenericDecoratedComponent Relationships conformant
   implementation.

5.18.1.  SUPAPolicyConcreteMetadata Attributes

   Currently, no relationships two attributes are defiend defined for the
   SUPAGenericDecoratedComponent class (note
   SUPAPolicyConcreteMetadata class, and are described in the
   following subsections.

5.18.1.1.  The Attribute "supaPolMDValidPeriodEnd"

   This is an optional attribute. Its data type should be able to
   express a date and a time. This attribute defines the ending
   date and time that this Metadata object is valid for.

5.18.1.2.  The Attribute "supaPolMDValidPeriodStart"

   This is an optional attribute. Its data type should be able to
   express a date and a time. This attribute defines the starting
   date and time that this Metadata object is valid for.

5.18.2.  SUPAPolicyConcreteMetadata Relationships

   This class inherits the decorator
   pattern obviates the need for relationships such as those in [6]).
   SUPAGenericDecoratedComponent participates in a single relationship,
   SUPAHasDecoratedPolicyComponent, as defined of the SUPAPolicyMetadata
   class; see section 5.17.2. It can also be used by subclasses of
   the SUPAPolicyMetadataDecorator class, and hence, can participate
   in the SUPAHasMetadataDecorator aggregation; see section 5.7.3.

** This class is under discussion - please comment as to its utility **

5.13. 5.19.2.

5.19.  The Concrete Abstract Class "SUPAPolicyCollection"

   A SUPAPolicyCollection "SUPAPolicyMetadataDecorator"

   This is an optional concrete class that class, and is used to implement the decorator
   pattern (see section 4.2.1.2.) for metadata objects. This pattern
   enables
   a collection (e.g., set, bag, all or other, more complex, collections
   of elements) part of **arbitrary objects** one or more SUPAPolicyMetadataDecorator
   subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance.

   It is recommended that this class be defined and used as part of a SUPAPolicyClause. conformant
   implementation.

5.19.1.  SUPAPolicyMetadataDecorator Attributes

   Currently, no attributes are defined for this class.

5.19.2.  SUPAPolicyMetadataDecorator Relationships

   This class was derived from [2], but inherits the relationships of the SUPAPolicyMetadata
   class; see section 5.17.2. It also defines a single aggregation,
   SUPAHasMetadataDecorator, which is not present used to implement the decorator
   pattern, as described in [RFC3460], [4], [5], or [6].

5.13.1.  Motivation

   One of the problems with ECA policy rules following subsections.

5.19.2.1.  The Aggregation "SUPAHasMetadataDecorator"

   This is when a set an optional aggregation, and is part of events
   or conditions needs to be tested. For example, if a set of events decorator
   pattern. It is received, the policy system may need to wait for patterns of
   events used to emerge (e.g., any number of Events of type A, followed
   by either one event of type B or two events of type Event C).
   Similarly, for conditions, testing the value of enable a set concrete instance of attributes
   may need a
   SUPAPolicyMetadataDecorator to be performed. Both of these represent dynamically add behavior
   similar to a set
   SUPAPolicyConcreteMetadata object instance. The semantics of if-then-else statements or a switch statement. this
   aggregation are defined by the SUPAHasMetadataDecoratorDetail
   association class.

   It is typically not desirable for the policy system to represent
   each choice in such clauses as its own policy clause (i.e., a
   3-tuple), as recommended that this creates object explosion and poor performance.
   Furthermore, in these cases, it is often required to have aggregation be part of a set conformant
   implementation.

   The multiplicity of
   complex logic to be executed, where this aggregation is 0..1 on the logic varies according to aggregate
   (SUPAPolicyMetadataDecorator) side and 1..n on the particular event or condition part
   (SUPAPolicyMetadata) side. This means that was selected. It is much
   too complex to represent if this using separate objects, especially
   when the logic aggregation is application- and/or vendor-specific. However,
   recall that
   defined, then at least one SUPAPolicyMetadata object (e.g., a
   concrete subclass of the goals of SUPAPolicyMetadataDecorator) must also be
   instantiated and wrapped by this document was to facilitate
   the machine-driven construction SUPAPolicyConcreteMetadata object
   instance. The semantics of policies. Therefore, a solution
   to this problem aggregation are defined by the
   SUPAHasMetadataDecoratorDetail association class.

5.19.2.2.  The Association Class "SUPAHasMetadataDecoratorDetail"

   This is needed.

5.13.2.  Solution

   Therefore, this document an optional concrete association class, and defines the concept
   semantics of a collection the SUPAHasMetadataDecorator aggregation. The purpose
   of
   entities, called a SUPAPolicyCollection. Conceptually, this class is to use the items Decorator pattern to be collected (e.g., events or conditions) determine
   which SUPAPolicyMetadataDecorator object instances, if any, are aggregated in
   one or more SUPAPolicyCollection objects
   required to augment the functionality of the appropriate type.
   Another optional SUPAPolicyCollection
   SUPAPolicyConcreteMetadata object could be used to
   aggregate logic blocks (including SUPAPolicies) to execute.
   Once finished, all appropriate SUPAPolicyCollection objects instance that is being used.
   Three attributes are
   sent to an external system defined for evaluation.

   The computation(s) represented by this class, which are described
   in the SUPAPolicyCollection may following subsections.

   It is recommended that this association class be part of a larger SUPAPolicyClause, since SUPAPolicyCollection
   conformant implementation.

5.19.2.2.1.  The Attribute "supaPolMetadataDecConstraintEncoding"

   This is a
   subclass of SUPAPolicyComponentDecorator, an optional non-negative enumerated integer that defines
   how to interpret each string in the supaPolMetadataDecConstraint
   class attribute. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text

   Enumerations 0 and can be used 1 signify an error state and an initialization
   state, respectively. Enumerations 2-4 are dedicated to
   decorate a SUPAPolicyClause. Therefore, OCL (with
   OCL 2.4 being the external system latest version as of this writing). QVT defines a
   set of languages [20] (the two most powerful and useful are defined
   by enumerations 5 and 6). Alloy is
   responsible a language for providing describing
   constraints, and uses a Boolean TRUE or FALSE return value, so
   that the policy system can use that value SAT solver to represent the
   computation guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but is included for completeness.

   If this class is instantiated, then this attribute SHOULD also be
   instantiated, and SHOULD be part of the function(s) performed in the
   SUPAPolicyCollection in a Boolean clause.

5.13.3.  SUPAPolicyCollection Attributes

   Currently, SUPAGenericDecoratedComponent defines five attributes,
   as described below.

5.13.3.1. conformant implementation.

5.19.2.2.2.  The Attribute "supaPolCollectionContent[0..n]" "supaPolMetadataDecConstraint[0..n]"

   This is an optional attribute that defines an array of strings.
   Each string in attributes. Each attribute
   specifies a constraint to be applied using the array identifies format identified
   by the value of the supaPolMetadataDecConstraintEncoding class
   attribute. This provides a domain-suitable identifier more rigorous and flexible treatment of
   an object that
   constraints than is collected by possible in [RFC3460].

   If this SUPAPolicyCollection instance. class is instantiated, then this attribute SHOULD also be
   instantiated, and should be part of a conformant implementation.
   Note: [0..n] means that this is a multi-valued property that has
   zero or more attributes.

5.13.3.2.

5.19.2.2.3.  The Attribute "supaPolCollectionEncoding" "supaPolMetadataDecIsApplicable"

   This is an optional non-negative enumerated integer that defines
   the data type of the content of this collection instance. Values
   include:

     0:  error
     1:  init
     2:  by regex (regular expression)
     3:  by URI

   Note that 0 and 1 represent error and initialization states,
   respectively. Boolean attribute. If the value of this
   attribute is 2, TRUE, then each of the
   strings SUPAPolicyMetadataDecorator object(s) of
   this particular SUPAHasMetadataDecorator aggregation SHOULD be
   aggregated by this particular SUPAPolicyConcreteMetadata object.

5.20.  The Concrete Class "SUPAPolicyAccessMetadataDef"

   This is an optional concrete class that defines access control
   information, in the supaPolCollectionContent attribute represent a regex form of metadata, that contains can be added to a
   SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata
   aggregation (see section 5.2.2.). This enables all or part of a string to match the class name
   standardized description and/or specification of the
   object that is access control
   for a given SUPAPolicyObject to be collected easily changed at runtime by this
   wrapping an object instance of a
   SUPAPolicyCollection class. If the value SUPAPolicyConcreteMetadata
   class (or its subclass) with all or part of this attribute is 3, object, and then each of
   adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata
   object instance.

5.20.1.  SUPAPolicyAccessMetadataDef Attributes

   Currently, the strings SUPAPolicyAccessMetadataDef class defines three
   attributes; these are described in the supaPolCollectionContent attribute
   represent a URI.

5.13.3.3. following subsections.

5.20.1.1.  The Attribute "supaPolCollectionFunction" "supaPolAccessPrivilegeDef"

   This is an optional non-negative enumerated integer that defines attribute. It
   specifies the function access privileges that external Applications have
   when interacting with a specific SUPAPolicyObject that is adorned
   with an instance of this collection instance. SUPAPolicyAccessMetadataDef object. This
   enables the management system to control, in a consistent manner,
   the set of operations that external Applications have for
   SUPAPolicies and components of SUPAPolicies. Values include:

      0:  error
      1:  init
      2:  event collection  read only (for all policy components)
      3:  condition collection  read and write (for all policy components)
      4:  action collection  privileges are specified by an external MAC model
      5:  logic collection  privileges are specified by an external DAC model
      6:  privileges are specified by an external RBAC model
      7:  privileges are specified by an external ABAC model
      8:  privileges are specified by an external custom model

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 2-4 define 4-8 indicate that a collection formal external access
   control model is used. The name of objects that this model, and its location,
   are to
   be used to populate the event, condition, or action clauses,
   respectively, of a SUPAECAPolicyRule. specified in two other class attributes, called
   supaPolAccessPrivilegeModelName and supaPolAccessPrivilegeModelRef.

   MAC, DAC, RBAC, and ABAC (values 4-7 stand for Mandatory Access
   Control, Discretionary Access Control, Role-Based Access Control,
   and Attribute-Based Access Control, respectively. They are defined
   in [13]. A value of 4 8 indicates that
   this collection contains objects that define logic for processing a SUPAPolicy.

5.13.3.4. formal external model that
   is not MAC, DAC, RBAC, or ABAC is used.

5.20.1.2.  The Attribute "supaPolCollectionIsOrdered" "supaPolAccessPrivilegeModelName"

   This is an optional Boolean attribute. string attribute that contains the name of
   the access control model being used. If the value of the
   supaPolAccessPrivilegeDef is 0-2, then the value of this attribute
   is TRUE, then all elements not applicable. Otherwise, the text in this instance class attribute
   should be interpreted according to the value of this
   SUPAPolicyCollection are ordered.

5.13.3.5. the
   supaPolAccessPrivilegeModelRef class attribute.

5.20.1.3.  The Attribute "supaPolCollectionType" "supaPolAccessPrivilegeModelRef"

   This is an optional non-negative enumerated integer attribute
   that defines the data type of collection that the supaPolAccessPrivilegeModelName
   attribute. If the value of the supaPolAccessPrivilegeDef class
   attribute is 0-2, then the value of this instance is. attribute is not
   applicable. Otherwise, the value of this class attribute defines
   how to interpret the text in the supaPolAccessPrivilegeModelRef
   class attribute. Values include:

      0:  error
      1:  init
      2:  set  GUID
      3:  bag (e.g., multi-set)  UUID
      4:  dictionary (e.g., associative array)  URI
      5:  FQDN
      6:  FQPN
      7:  string_instance_id

   Note that 0 and 1 represent error and initialization states,
   respectively. A set is an unordered collection of elements that MUST
   NOT have duplicates. A bag is an unordered collection of elements;
   it MAY have duplicates.  A dictionary is a table that associates a
   key with a value.

   Sets have a number of important functions, including:

      o membership:   returns TRUE if the element being tested is
                      in the set, and FALSE otherwise
      o subset:       returns TRUE if all elements in the first set
                      are also in the second set
      o union:        returns all elements from both sets with no
                      duplicates
      o intersection: returns all elements that are in both sets
                      with no duplicates
      o difference:   returns all elements in the first set that
                      are not in the second set

   Bags have a number of important functions in addition to the
   functions defined for sets (note that while the above set of
   functions for a set that 0 and 1 represent error and initialization states,
   respectively. Values 2-6 define the content as a bag are reference. Value 7
   defines the same, content as a bag string that is a different
   data type than a set):

      o multiplicity:  returns the number canonical
   representation, in ASCII, of occurrences an instance ID of this object.

5.21.  The Concrete Class "SUPAPolicyVersionMetadataDef"

   This is an
                       element optional concrete class that defines versioning
   information, in the bag
      o count:         returns the number of all items, including
                       duplicates
      o countDistinct: returns the number form of items, where metadata, that can be added to a
   SUPAPolicyObject. This enables all
                       duplicates are ignored

   A dictionary is an unordered set or part of key:value pairs, where each
   key is unique within a given dictionary. The combination standardized
   description and/or specification of version information for a
   key and a value is called
   given SUPAPolicyObject to be easily changed at runtime by
   wrapping an item. The format object instance of an item the SUPAPolicyConcreteMetadata
   class (or its subclass) with all or part of this object.

5.21.1.  SUPAPolicyVersionMetadataDef Attributes

   Version information is 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
   separated by a comma. Keys generic format based on the
   Semantic Versioning Specification [18] as follows:

      <major>.<minor>.<patch>[<pre-release>][<build-metadata>]

   where the first three components (major, minor, and patch) MUST NOT be NULL; values
   present, and the latter two components (pre-release and build-
   metadata) MAY be NULL.

   An example 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 a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}.
   An example each of these three elements MUST
   increase numerically.  In this approach:

      o supaVersionMajor denotes a null dictionary new release; this number MUST be
        incremented when either changes are introduced that are not
        backwards-compatible, and/or new functionality not previously
        present is simply {}.

5.13.4.  SUPAPolicyCollection Relationships

   Currently, no relationships introduced
      o supaVersionMinor denotes a minor release; this number MUST be
        incremented when new features and/or bug fixes to a major
        release that are defined for the
   SUPAGenericDecoratedComponent class (note 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 decorator
   pattern obviates following rules define their
   precedence:

      1.  Precedence MUST be calculated by separating the need for relationships such as those in [6]).
   SUPAPolicyCollection participates in a single relationship,
   SUPAHasDecoratedPolicyComponent, as defined version into
          major, minor, patch, and pre-release identifiers, in section 5.7.3.

5.14.  The Concrete Class "SUPAPolicySource"

   This is an optional class that defines
          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 set difference is found as follows:
                - identifiers consisting only of managed entities
   that authored, or digits are otherwise responsible for, this
   SUPAPolicyRule. Note that a SUPAPolicySource does NOT
   evaluate or execute SUPAPolicies. Its primary use is for
   auditability compared
                  numerically and the implementation of deontic identifiers with letters and/or alethic logic.
   A class diagram is shown
                  hyphens are compared lexically in Figure 12. ASCII sort order
                - Numeric identifiers always have lower precedence
                  than non-numeric identifiers
                - A SUPAPolicySource SHOULD be mapped to a role or larger set of roles
   (e.g., using the role-object pattern [11]). This enables
   role-based access control to be used to restrict which entities
   can author pre-release fields has a given policy. Note that Role is higher
                  precedence than a type smaller set, if all of
   SUPAPolicyMetadata.

5.14.1.  SUPAPolicySource Attributes 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, no attributes the SUPAPolicyVersionMetadataDef class defines five
   attributes; these are defined for this class.

5.14.2.  SUPAPolicySource Relationships

   SUPAPolicySource participates in a single relationship,
   SUPAHasPolicySource, as defined described in section 5.3.2.1.
   SUPAPolicySource, and its subclasses, inherit the
   SUPAHasDecoratedPolicyComponent aggregation, which was
   defined in section 5.7.3.

5.15. following subsections.

5.21.1.1.  The Concrete Class "SUPAPolicyTarget" Attribute "supaVersionMajor"

   This is an optional class that defines a set mandatory string attribute, and contains a string
   representation of managed entities an integer that a SUPAPolicy is applied to. Figure 12 shows a class diagram
   of the SUPAPolicyTarget.

   A managed object must satisfy two conditions in order greater than or equal to be defined
   as a SUPAPolicyTarget. First, the set of managed entities zero.
   It indicates that are
   to be affected by the SUPAPolicy must all agree to play the role of
   a SUPAPolicyTarget. In general, a managed entity may or may not be significant increase in a state functionality is
   present in this version. It MAY also indicate that enables SUPAPolicies to this version has
   changes that are NOT backwards-compatible; this MAY be applied to it to change
   its state; hence, a negotiation process may need to occur to enable denoted in
   the SUPAPolicyTarget to signal when it supaVersionBuildMetadata class attribute.

   The special string "0.1.0" is willing to have
   SUPAPolicies applied to it. Second, a SUPAPolicyTarget must for initial development that MUST
   NOT be able
   to process (directly or with the aid of a proxy) SUPAPolicies.

   If a proposed SUPAPolicyTarget meets both of these conditions, it
   SHOULD set its supaPolicyTargetEnabled Boolean attribute considered stable. Improvements to a
   value of TRUE.

   A SUPAPolicyTarget SHOULD be mapped this initial version,
   before they are released to a role (e.g., using the
   role-object pattern). This enables role-based access control to
   be used to restrict which entities can author a given policy.
   Note that Role is a type of SUPAPolicyMetadata.

5.15.1.  SUPAPolicyTarget Attributes

   Currently, no attributes public, are defined for denoted by incrementing
   the SUPAPolicyTarget
   class.

5.15.2.  SUPAPolicyTarget Relationships

   SUPAPolicyTarget participates in a single relationship,
   SUPAHasPolicyTarget, as defined in section 5.3.2.3.

5.16. 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.21.1.2.  The Abstract Class "SUPAPolicyMetadata"

   Metadata Attribute "supaVersionMinor"

   This is information that describes and/or prescribes
   characteristics a mandatory string attribute, and behavior contains a string
   representation of another object an integer that is **not**
   an inherent, distinguishing characteristic greater than or behavior of equal to zero.
   It indicates that
   object (otherwise, it would be an integral part this release contains a set of features and/or
   bug fixes that object).

   For example, a socialSecurityNumber attribute should not MUST be part
   of a generic Person class. First, most countries in backwards-compatible.

   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 world do
   not know what a social security minor version number is, much less use them.
   Second, a person is not created with incremented.

5.21.1.3.  The Attribute "supaVersionPatch"

   This is a social security number;
   rather, mandatory string attribute, and contains a social security number string
   representation of an integer that is used greater than or equal to track people for
   administering social benefits, though it zero.
   It indicates that this version contains ONLY bug fixes.

   The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented
   if new, backwards-compatible changes are introduced. A bug fix is also used
   defined as an internal change that fixes incorrect behavior.

5.21.1.4.  The Attribute "supaVersionPreRelease"

   This is an optional string attribute, and contains a form
   of identification.

   Continuing string
   defining the example, pre-release version.

   A pre-release version MAY be denoted by appending a better way to add this capability to hyphen and a
   model would
   series of dot-separated identifiers immediately following the patch
   version. Identifiers MUST comprise only ASCII alphanumerics and a
   hyphen. Identifiers MUST NOT be to empty. Numeric identifiers MUST NOT
   include leading zeroes. Pre-release versions have a generic Identification class, then
   define a SocialSecurityNumber subclass, populate it 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 necessary, denoted by its associated
   normal version. Examples include: 1.0.0-alpha,
   1.0.0-alpha.1, 1.0.0-0.3.7, and then define 1.0.0-x.7.z.92.

5.21.1.5.  The Attribute "supaVersionBuildMetadata"

   This is an optional string attribute, and contains a composition between string defining
   the build metadata. Build metadata MAY be denoted by appending a Person
   plus sign and it (this is a
   composition because social security numbers are not reused).

   Since social security numbers are given to US citizens, permanent
   residents, series of dot-separated identifiers immediately
   following the patch or pre-release version. Identifiers MUST be
   made up of only ASCII alphanumerics and temporary working residents, 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 because it is
   also used to administer benefits, 1.0.0-beta+exp.sha.5114f85.

6.  SUPA ECAPolicyRule Information Model

   This section defines the composition is realized
   as an association class to define how it is being used.

   An example classes, attributes, and relationships
   of the SUPA ECAPolicyRule Information Model (EPRIM). Unless
   otherwise stated, all classes (and attributes) defined in this
   section were abstracted from DEN-ng [2], and a version of descriptive metadata for network elements would be
   documentation about best current usage practices (this could also
   be them are
   in the form process of being added to [5].

6.1.  Overview

   Conceptually, the EPRIM is a reference). An example set of prescriptive
   metadata subclasses that specialize the
   concepts defined in the GPIM for network elements would be representing the definition components of a time
   period during which specific types of operations are allowable.
   Policy that uses ECA semantics. This is an optional class shown in Figure 26 (only
   new EPRIM subclasses and their GPIM superclasses are shown; note
   that defines the top of a SUPAPolicyMetadata hierarchy is used **as is**).

   (Class of another model elements that are used SUPA is integrating into)
       |
       +---SUPAPolicyObject (5.2)
             |
             +---SUPAPolicyStructure (5.3)
             |     |
             |     +---SUPAECAPolicyRule (6.4)
             |          |
             |          +---SUPAECAPolicyRuleAtomic (6.5)
             |          |
             |          +---SUPAECAPolicyRuleComposite (6.6)
             |
             +---SUPAPolicyComponentStructure (5.4)
                   |
                   +---SUPAPolicyClause (5.5)
                   |     |
                   |     +---SUPABooleanClause (6.7)
                   |          |
                   |          +---SUPABooleanClauseAtomic (6.8)
                   |          |
                   |          +---SUPABooleanClauseComposite (6.9)
                   |
                   +---SUPAPolicyClauseComponentDecorator (5.7)
                         |
                         +---SUPAECAComponent(6.10)
                               |
                               +---SUPAPolicyEvent (6.11)
                               |
                               +---SUPAPolicyCondition (6.12)
                               |
                               +---SUPAPolicyAction (6.13)

              Figure 26.  The EPRIM Class Hierarchy

   Specifically, the EPRIM specializes the SUPAPolicyStructure class
   class to define different types create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it
   also specializes two subclasses of metadata
   that can be applied the SUPAPolicyComponentStructure
   class to create two new sets of policy and policy component objects. This
   enables common metadata components. These two
   SUPAPolicyComponentStructure subclasses are:

      o a new subclass of SUPAPolicyClause, called SUPABooleanClause
        (see sections 6.7 - 6.9), is defined for constructing Boolean
        clauses that are specific to be the needs of ECA Policy Rules
      o a new subclass of SUPAPolicyClauseComponentDecorator, called
        SUPAECAComponent (see sections 6.10 - 6.13), is defined as for
        constructing reusable objects that represent Events,
        Conditions, and then reused
   when Actions

   The EPRIM provides new functionality, based on the metadata are applicable. One way GPIM, by
   extending the GPIM to control whether
   SUPAPolicyMetadata objects define new classes and relationships. The
   EPRIM does NOT define new classes that are reused is by using not inherited from
   existing GPIM classes. This ensures that the attributes semantics of the SUPAHasPolicyMetadataDetail association class.

   It is recommended that this class, along with its
   SUPAPolicyConcreteMetadata GPIM
   are not changed, even though new functionality (for ECA Policy
   Rules and SUPAPolicyMetadataDecorator
   subclasses, be used components) are being defined.

   The overall strategy for refining the GPIM is as part of a conformant implementation. It follows:

      o SUPAECAPolicyRule is defined to be optional, since metadata is not strictly required.
   However, metadata can help specify and describe SUPAPolicyObject
   entities, as a subclass of the GPIM
        SUPAPolicyStructure class
      o A SUPAECAPolicyRule has event, condition, and action clauses
        o Conceptually, this can also be used to drive dynamic behavior.

5.16.1.  SUPAPolicyMetadata Attributes

   This section defines the attributes of viewed as three aggregations
          between the SUPAPolicyMetadata
   class.

5.16.1.1.  The Attribute "supaPolMetadataDescription"

   This is SUPAECAPolicyRule and each clause
        o Each aggregation uses an optional string attribute that defines instance of a free-form
   textual description concrete subclass of
          SUPAPolicyClause; this metadata object.

5.16.1.2.  The Attribute "supaPolMetadataIDContent"

   This is can be a mandatory string attribute that represents part of the
   object identifier SUPABooleanClause
          (making it ECA-specific), a SUPAEncodedClause (making it
          generic in nature), or a new subclass of an instance SUPAPolicyClause
        o Concrete subclasses of this class. It defines the
   content SUPAPolicyClause may be decorated
          with zero or more concrete subclasses of the object identifier. It works with another
          SUPAPolicyComponentDecorator class
   attribute, called supaPolMetadataIDEncoding, which defines how to
   interpret this attribute. These two attributes form a tuple,
   and together enable a machine
      o An optional set of GPIM SUPAPolicySource objects can be
        defined to understand represent the syntax and value authoring of an object identifier for a SUPAECAPolicyRule
      o An optional set of GPIM SUPAPolicyTarget objects can be
        defined to represent the object instance set of managed entities that will be
        affected by this class.

5.16.1.3.  The Attribute "supaPolMetadataIDEncoding"

   This is an SUPAECAPolicyRule
      o An optional non-zero enumerated integer attribute that
   represents part of the object identifier set of an instance SUPAPolicyMetadata can be defined for any
        of this
   class. It defines the format objects that make up a SUPAECAPolicyRule, including
        any of the object identifier. It works
   with another class attribute, called supaPolMetadataIDContent, its components

6.2.  Constructing a SUPAECAPolicyRule

   There are several different ways to construct a SUPAECAPolicyRule;
   they differ in which defines set of components are used to define the
   content of the object ID.

   These two attributes form a tuple, SUPAECAPolicyRule, and together enable whether each component is
   decorated or not. The following are some examples of creating a machine
   to understand the syntax and value
   SUPAECAPolicyRule:

      o Define three types of an object identifier SUPABooleanClauses, one each for the object instance of this class. The supaPolMetadataIDEncoding
   attribute is mapped to the following values:

      0:  error
      1:  init
      2:  GUID
      3:  UUID
      4:  URI
      5:  FQDN
      6:  FQPN
      7:  string_instance_id

   Note that 0 and 1 represent error
        event, condition, and initialization states,
   respectively. Values 2-6 define the content as a reference. Value 7
   defines the content as a string action clauses that is the canonical
   representation, in ASCII, make up a
        SUPAECAPolicyRule, and then
        o For one or more of the above clauses, associate an instance ID
          appropriate set of this object.

5.16.1.4.  The Attribute "supaPolMetadataName"

   This is an optional string attribute that defines SUPAPolicyEvent, SUPAPolicyCondition, or
          SUPAPolicyAction objects, and complete the name of this
   SUPAPolicyMetadata object.

5.16.2.  SUPAPolicyMetadata Relationships

   SUPAPolicyMetadata participates in clause using an
          appropriate SUPAPolicyOperator and a single aggregation, which is
   defined corresponding
          SUPAPolicyValue or SUPAPolicyVariable (e.g., resulting in
          the following subsections.

5.16.2.1.  The Aggregation "SUPAHasPolicyMetadata"

   This is phrase "SUPAPolicyAction = SUPAPolicyEvent")
        o Define a mandatory aggregation that defines the set of
   SUPAPolicyMetadata that are aggregated by this particular
   SUPAPolicyObject. It SUPAPolicyCollection component, which is recommended that this aggregation be used
   as part of to
          aggregate a conformant implementation.

   The multiplicity set of this relationship is defined as 0..n on the
   aggregate (SUPAPolicyObject) side, objects appropriate for a clause, and 0..n on
          complete the part
   (SUPAPolicyMetadata) side. This means clause using an appropriate SUPAPolicyOperator
          and a corresponding SUPAPolicyValue or SUPAPolicyVariable
      o Create a new concrete subclass of
        SUPAPolicyClauseComponentDecorator (i.e., a sibling class of
        SUPAECAComponent) that this relationship is
   optional. The semantics can wrap concrete instances of
        SUPAPolicyClause (i.e., SUPABooleanClause); note that this aggregation are implemented using
        approach enables the SUPAHasPolicyMetadataDetail association class.

5.16.2.2.  The Abstract Class "SUPAHasPolicyMetadataDetail"

   This is a mandatory new concrete association class, and defines the
   semantics subclass of the SUPAHasPolicyMetadata aggregation. Its purpose is
        SUPAPolicyClauseComponentDecorator to determine which SUPAPolicyMetadata object instances should optionally be
   attached to which particular object instances decorated
        as well
      o Create a new concrete subclass of the
   SUPAPolicyObject class. This is done SUPAPolicyStructure that
        provides ECA-specific functionality, and define all or part
        of its content by using the attributes and
   relationships aggregating a set of the SUPAPolicyMetadataDetail class to constrain
   which SUPAPolicyMetadata objects can SUPAPolicyClauses

   Note that compound Boolean clauses may be aggregated by which
   particular SUPAPolicyObject instances. formed using one or more
   SUPABooleanClauseComposite objects with one or more
   SUPABooleanClauseAtomic objects.

6.3.  Working With SUPAECAPolicyRules

   A SUPAECAPolicyRule is a type of SUPAPolicy. It is recommended a tuple that this
   association class be used
   MUST have three clauses, defined as part of a conformant implementation.

5.16.2.2.1. follows:

      o The Attribute "supaPolMetadataIsApplicable"

   This is an optional event clause defines a Boolean attribute. If expression that, if TRUE,
        triggers the value evaluation of this
   attribute its condition clause (if the
        event clause is not TRUE, then the SUPAPolicyMetadata object(s) of this
   particular SUPAHasPolicyMetadata aggregation SHOULD be aggregated
   by no further action for this particular SUPAPolicyObject.

5.16.2.2.2.
        policy rule takes place).
      o The Attribute "supaPolMetadataConstraintEncoding"

   This is an optional non-negative enumerated integer that condition clause defines
   how to interpret each string a Boolean expression that, if
        TRUE, enables the actions in the supaPolMetadataConstraint
   class attribute. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text

   Enumerations 1 and 2 signify an error state and an initialization
   state, respectively. Enumeraitons 3-5 are dedicated action clause to OCL (with
   OCL 2.4 being be executed
        (if the latest version as of condition clause is not TRUE, then no further action
        for this writing). QVT defines policy rule takes place).

      o The action clause contains a set of languages [20] (the two most powerful and useful actions that MAY be
        executed; which particular actions are executed are defined
        by enumerations 5 and 6). Alloy is a language for describing
   constraints, and uses a SAT solver to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal, metadata and hence, not verifiable), but is included for completeness.

   If this class is instantiated, then this the supaECAEvalStrategy attribute SHOULD also be
   instantiated, and SHOULD be part of a conformant implementation.

5.16.2.2.3.  The Attribute "supaPolMetadataConstraint[0..n]"

   This is an optional array of string attributes. (see
        section 6.6.1.1.).

   Each attribute
   specifies a constraint to be applied using the format identified
   by the value of the supaPolMetadataPolicyConstraintEncoding class
   attribute. This provides above clauses can be a more rigorous and flexible treatment simple Boolean expression (of
   the form {variable operator value}, or a compound Boolean
   expression consisting of
   constraints than is possible in [RFC3460].

   If this class is instantiated, then this attribute Boolean combinations of clauses.
   Compound Boolean expressions SHOULD also be
   instantiated, and should be part in CNF or DNF.

   Note that each of the above three clauses MAY have a conformant implementation.
   Note: [0..n] means set of
   SUPAPolicyMetadata objects that this can constrain, or otherwise
   affect, how that clause is treated. For example, a multi-valued property that has
   zero set of
   SUPAPolicyMetadata MAY affect whether none, some, or more attributes.

5.17.  The Concrete Class "SUPAPolicyConcreteMetadata"

   This is an optional concrete class. It defines all actions
   are executed, and what happens if an object that will
   be wrapped by concrete instances action fails.

   Each of the SUPAPolicyMetadataDecorator
   class. It three clauses can be viewed as constructed from either a "carrier" for metadata that will be
   attached to
   SUPAEncodedClause or a subclass SUPABooleanClause. The advantage of using
   SUPAEncodedClauses is simplicity, as the content of SUPAPolicyObject. Since the decorator
   pattern clause is used, any number of concrete subclasses of
   encoded directly into the
   SUPAPolicyMetadataDecorator class can wrap an instance attributes of the
   SUPAPolicyConcreteMetadata class.

   It SUPAEncodedClause. The
   advantage of using SUPABooleanClauses is recommended that this class reusability, since each
   term in each clause is potentially a reusable object.

   Since a SUPABooleanClause is a subclass of a SUPAPolicyClause
   (see Section 6.7), it can be used as part decorated by one or more concrete
   subclasses of SUPAPolicyClauseComponentDecorator. Therefore, a conformant
   implementation.

5.17.1.  SUPAPolicyConcreteMetadata Attributes

   Currently, two attributes are
   SUPAECAPolicyRule can be built entirely from objects defined for in
   the
   SUPAPolicyConcreteMetadata class, GPIM and are described in EPRIM, which facilitates the
   following subsections.

5.17.1.1. construction of
   SUPAPolicies by a machine.

   The Attribute "supaPolMDValidPeriodEnd"

   This is an optional attribute. Its data type should be able to
   express relation between a date SUPAECAPolicyRule and a time. This attribute defines the ending
   date SUPAPolicyClause
   is shown in Figure 27, and time that this Metadata object is valid for.

5.17.1.2. further explained in Section 6.4.

  A                                               A
 +---------------------+                         +------------------+
 |                     |/ \ SUPAHasPolicyClause \|                  |
 | SUPAPolicyStructure | A ---------+------------+ SUPAPolicyClause |
 |                     |\ /         ^           /|                  |
 +---------+-----------+ 0..n       |       1..n +--------+---------+
          / \                       |                    / \
           I                        |                     I
    A      I                        |             A       I
   +-------+-----------+            |            +--------+----------+
   | SUPAECAPolicyRule |            |            | SUPABooleanClause |
   +-------------------+            |            +-------------------+
                                    |
                     A              |
                    +---------------+-----------+
                    | SUPAHasPolicyClauseDetail |
                    +---------------------------+

                Figure 27.  SUPAECAPolicyRule Clauses

   The Attribute "supaPolMDValidPeriodStart" SUPAHasPolicyClause aggregation is implemented using the
   SUPAHasPolicyClauseDetail association class. These were
   described in sections 5.3.2.7 and 5.3.2.8, respectively.

6.4.  The Abstract Class "SUPAECAPolicyRule"

   This is an optional attribute. Its data type should be able to
   express a date and mandatory abstract class, which is a time. This attribute defines the starting
   date and time PolicyContainer
   that aggregates PolicyEvents, PolicyConditions, PolicyActions into
   a type of policy rule known as an Event-Condition-Action (ECA)
   policy rule. As previously explained, this Metadata object is valid for.

5.17.2.  SUPAPolicyConcreteMetadata Relationships

   This class inherits has the relationships of following
   semantics:

      IF the SUPAPolicyMetadata
   class; see section 5.16.2. It can also event clause evaluates to TRUE
         IF the condition clause evaluates to TRUE
            THEN execute actions in the action clause
         ENDIF
      ENDIF

   The event clause, condition clause, and action clause collectively
   form a three-tuple. Each clause MUST be used defined by at least one
   SUPAPolicyClause (which MAY be decorated with other elements,
   using concrete subclasses of the SUPAPolicyMetadataDecorator SUPAPolicyClauseComponentDecorator
   class, and hence, can participate as described in the SUPAHasMetadataDecorator aggregation; see section 5.18.2.

5.18.  The Abstract Class "SUPAPolicyMetadataDecorator"

   This 5.7).

   Each of the three types of clauses is an optional class, a 3-tuple of the form:

      {variable operator value}

   Each of the three clauses MAY be combined with additional clauses
   using any combination of logical AND, OR, and NOT operators; this
   forms a "compound" Boolean clause. For example, if A, B, and C are
   three attributes in an event, then a valid event clause could be:

      (A AND B) OR C

   Note that the above expression is used to implement in DNF; the decorator
   pattern (see section 5.7.1.) for metadata objects. This pattern
   enables equivalent CNF form
   is ((A OR C) AND (B OR C)). In either case, the output of all
   three clauses is either TRUE or part of one FALSE; this facilitates combining
   and chaining SUPAECAPolicyRules.

   An action clause MAY invoke a SUPAPolicyAction from the same or more SUPAPolicyMetadataDecorator
   subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance.

   It is recommended that this class
   different SUPAECAPolicyRule. However, a SUPAPolicy MUST NOT be used as part of
   called directly by a conformant
   implementation.

5.18.1.  SUPAPolicyMetadataDecorator Attributes

   Currently, no attributes are defined for the
   SUPAPolicyMetadataDecorator class.

5.18.2.  SUPAPolicyMetadataDecorator Relationships

   This class inherits SUPAECAPolicyRule action clause; this is
   because the relationships semantics of the a SUPAECAPolcyRule dictate that some type
   of event triggers its evaluation (among other reasons).

   An ECAPolicyRule MAY be optionally augmented with SUPAPolicySource
   and/or SUPAPolicyTarget objects (see sections 5.15 and 5.16,
   respectively).

   All objects that make up a SUPAECAPolicyRule MAY have
   SUPAPolicyMetadata
   class; see objects (see section 5.16.2. It also defines a single aggregation,
   SUPAHasMetadataDecorator, which is used 5.17) attached to implement the decorator
   pattern, as described them to
   further describe and/or specify behavior.

   When defined in an information model, each of the following subsections.

5.18.2.1.  The Aggregation "SUPAHasMetadataDecorator"

   This is event, condition,
   and action clauses MUST be represented as an optional aggregation, aggregation between a
   SUPAECAPolicyRule (the aggregate) and is part a set of event, condition,
   or action objects (the components). However, a decorator
   pattern. It is used data model MAY map
   these definitions to enable a concrete instance more efficient form (e.g., by flattening
   these three types of object instances, along with their respective
   aggregations, into a
   SUPAPolicyMetadataDecorator to dynamically add behavior to a
   SUPAPolicyConcreteMetadata single object instance. instance).

   The semantics of this
   aggregation are defined by the SUPAHasMetadataDecoratorDetail
   association class.

   It composite pattern [3] is recommended that this aggregation applied to the SUPAECAPolicyRule
   class, enabling its (concrete) subclasses to be part of used as either a conformant
   implementation.

   The multiplicity
   stand-alone policy rule or as a hierarchy of this aggregation is 0..1 on the aggregate
   (SUPAPolicyMetadataDecorator) side policy rules.
   SUPAECAPolicyRuleComposite and 1..n on the part
   (SUPAPolicyMetadata) side. SUPAECAPolicyRuleAtomic both
   inherit from SUPAECAPolicyRule. This means that if this aggregation is
   defined, then at least one SUPAPolicyMetadata object (e.g., a
   concrete subclass of SUPAPolicyMetadataDecorator) must also be
   instantiated and wrapped by this SUPAPolicyConcreteMetadata object
   instance. The semantics of this aggregation they are defined by the
   SUPAHasMetadataDecoratorDetail association class.

5.18.2.2.  The Association Class "SUPAHasMetadataDecoratorDetail"

   This is an optional concrete association class, and defines the
   semantics of the SUPAHasMetadataDecorator aggregation. The purpose both
   a type of this class is to use SUPAECAPolicyRule. Hence, the Decorator pattern to determine
   which SUPAPolicyMetadataDecorator HasSUPAECAPolicyRule
   aggregation enables a particular SUPAECAPolicyRuleComposite
   object instances, if any, are
   required to augment the functionality of the
   SUPAPolicyConcreteMetadata object instance that is being used.

   It is recommended that this association class be part of aggregate both SUPAECAPolicyRuleComposite as well as
   SUPAECAPolicyRuleAtomic objects. In contrast, a
   conformant implementation.

   Attributes for this association class will be
   SUPAECAPolicyRuleAtomic can NOT aggregate either a
   SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic.
   SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are
   defined in a future
   version of this document.

5.19.  The Concrete Class "SUPAPolicyAccessMetadataDef" sections 6.5 and 6.6, respectively. This is an optional concrete class that defines access control
   information,
   shown in Figure 28.

                               A
                         1..n +-------------------+
                             \|                   |
             +--------------- + SUPAECAPolicyRule |
             |               /|                   |
             |                +--------+----------+
             |                        / \
             | SUPAHasECAPolicyRule    I
             |                         I
             |                         I
             |                         I
             |         +---------------+-------------+
             |         I                             I
            / \        I                             I
             A         I                             I
        C   \ / 0..1   I                  C          I
       +-----+---------+----------+      +-----------+-----------+
       |SUPAECAPolicyRuleComposite|      |SUPAECAPolicyRuleAtomic|
       +--------------------------+      +-----------------------+

   Figure 28.  The Composite Pattern Applied to a SUPAECAPolicyRule
   Note that the form of metadata, that can be added to a
   SUPAPolicyObject. This is done using the SUPAHasPolicyMetadata HasSUPAECAPolicyRule aggregation (see section 5.2.2.). This enables all or part of a
   standardized description and/or specification of access control
   for a given SUPAPolicyObject to be easily changed at runtime is defined by
   wrapping an object instance of the SUPAPolicyConcreteMetadata
   class (or its subclass) with all or part of this object,
   HasSUPAECAPolicyRuleDetail association class; both are defined
   in sections 6.6.2 and then
   adorning the SUPAPolicyObject with the SUPAPolicyConcreteMetadata
   object instance.

5.19.1.  SUPAPolicyAccessMetadataDef 6.6.3, respectively.

6.4.1.  SUPAECAPolicyRule Attributes

   Currently, the SUPAPolicyAccessMetadataDef class SUPAECAPolicyRule defines three
   attributes; these are two attributes, as
   described in the following subsections.

5.19.1.1.

6.4.1.1.  The Attribute "supaPolAccessPrivilegeDef" "supaECAPolicyRulePriority"

   This is an optional a mandatory non-negative enumerated integer attribute. It
   specifies the access privileges that external Applications have
   when interacting with a specific SUPAPolicyObject attribute that is adorned
   with an instance of this SUPAPolicyAccessMetadataDef object. This
   enables the management system to control, in a consistent manner, defines
   the set of operations that external Applications have for
   SUPAPolicies and components of SUPAPolicies. Values include:

      0:  error
      1:  init
      2:  read only (for all policy components)
      3:  read and write (for all policy components)
      4:  privileges are specified by an external MAC model
      5:  privileges are specified by an external DAC model
      6:  privileges are specified by an external RBAC model
      7:  privileges are specified by an external ABAC model
      8:  privileges are specified by an external custom model

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 4-8 indicate that a formal external access
   control model is used. The name priority of this model, and its location,
   are specified in two other class attributes, called
   supaPolAccessPrivilegeModelName and supaPolAccessPrivilegeModelRef.

   MAC, DAC, RBAC, and ABAC (values 4-7 stand for Mandatory Access
   Control, Discretionary Access Control, Role-Based Access Control,
   and Attribute-Based Access Control, respectively. They are defined
   in [22]. particular SUPAECAPolicyRule. A larger value of 8
   indicates that a formal external model that
   is not MAC, DAC, RBAC, or ABAC is used.

5.19.1.2.  The Attribute "supaPolAccessPrivilegeModelName"

   This is an optional string attribute that contains the name of
   the access control model being used. If the higher priority. A default value of the
   supaPolAccessPrivilegeDef 0 MAY be assigned.

   Priority is 0-2, then the value used primarily for 2 reasons: (1) to resolve conflicts
   among policy actions (e.g., given a set of this attribute
   is not applicable. Otherwise, the text in this class attribute
   should be interpreted according conflicting actions,
   which one will execute) and (2) to define the value execution order of
   policy actions (e.g., when one action may depend on the
   supaPolAccessPrivilegeModelRef class attribute.

5.19.1.3. output of
   one or more previous actions).

6.4.1.2.  The Attribute "supaPolAccessPrivilegeModelRef" "supaECAPolicyRuleStatus"

   This is an optional non-negative enumerated integer attribute
   that defines the data type of the supaPolAccessPrivilegeModelName
   attribute. If the value of the supaPolAccessPrivilegeDef class
   attribute is 0-2, then the whose value of this attribute is not
   applicable. Otherwise,
   defines the value current status of this class attribute defines
   how to interpret the text in the supaPolAccessPrivilegeModelRef
   class attribute. policy rule. Values include:

     0:  error
     1:  init
     2:  GUID  In development, not ready to be deployed
     1:  Ready to be deployed
     2:  Deployed but not enabled
     3:  UUID  Deployed and enabled, but not executed
     4:  URI  Executed without errors
     5:  FQDN  Executed with errors
     6:  FQPN
      7:  string_instance_id  Aborted during execution

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 2-6 define the content as a reference. Value 7
   defines the content as a string that is

6.4.2.  SUPAECAPolicyRule Relationships

   Currently, the canonical
   representation, in ASCII, of an instance ID of this object.

5.20. SUPAECAPolicyRule does not define any
   relationships. It inherits all four relationships defined by
   the SUPAPolicyStructure class (see section 5.3.2.).

6.5.  The Concrete Class "SUPAPolicyVersionMetadataDef" "SUPAECAPolicyRuleAtomic"

   This is an optional a mandatory concrete class. This class that defines versioning
   information, in the form is a type of metadata,
   PolicyContainer, and represents a SUPAECAPolicyRule that can be added to a
   SUPAPolicyObject. This enables all or part of
   operate as a standardized
   description and/or specification of version information for single, stand-alone, manageable object.

   Put another way, a
   given SUPAPolicyObject to be easily changed at runtime by
   wrapping an SUPAECAPolicyRuleAtomic object instance of the SUPAPolicyConcreteMetadata
   class (or its subclass) with all or part can NOT be modeled
   as a set of hierarchical SUPAECAPolicyRule objects; if this object.

5.20.1.  SUPAPolicyVersionMetadataDef Attributes

   Version information is defined in
   required, then a generic format based on the
   Semantic Versioning Specification [18] as follows:

      <major>.<minor>.<patch>[<pre-release>][<build-metadata>]

   where the first three components (major, minor, and patch) MUST SUPAECAPolicyRuleComposite object should be
   present, and
   used instead.

6.5.1.  SUPAECAPolicyRuleAtomic Attributes

   Currently, the latter two components (pre-release and build-
   metadata) MAY be present. A version number MUST take SUPAECAPolicyRuleAtomic class defines a single
   attribute, as described in the form
   <major>.<minor>.<patch>, where <major>, <minor>, and <patch> are
   each non-negative integers following subsection.

6.5.1.1.  The Attribute "supaECAPolActionEvalStrategy"

   This is a mandatory, non-zero, integer attribute that MUST NOT contain leading zeros.
   In addition, the value enumerates
   a set of each allowable alternatives that define how the set of these three elements MUST
   increase numerically.

   In this approach:

      o supaVersionMajor denotes
   SUPAPolicyAction object instances in a new release; this number MUST be
        incremented when either changes are introduced that SUPAECAPolicyRuleAtomic
   object instance are not
        backwards-compatible, and/or new functionality not previously
        present evaluated. It is introduced
      o supaVersionMinor denotes a minor release; assumed that the event and
   condition clauses of this number MUST be
        incremented when new features and/or bug fixes SUPAECAPolicyRule have evaluated to a major
        release that are backwards-compatible are introduced, and/or
        if any features TRUE.
   This attribute controls which SUPAPolicyActions are marked as deprecated
      o supaVersionPatch denotes executed for a version that consists ONLY of bug
        fixes, and MUST be incremented
   given SUPAPolicyRuleAtomic object instance when these bug fixes are Not
        backwards-compatible

   When it contains multiple versions exist, the following rules define their
   precedence:

      1.  Precedence MUST be calculated by separating
   SUPAPolicyActions. Values include:

      0:  error
      1:  init
      2:  execute the version into
          major, minor, patch, and pre-release identifiers, first SUPAPolicyAction 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, SUPAPolicyRuleAtomic
          object 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 then terminate
      3:  execute the same
                major, minor, last SUPAPolicyAction in the SUPAPolicyRuleAtomic
          object 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 then terminate
      4:  execute only of digits are compared
                  numerically and identifiers with letters and/or
                  hyphens are compared lexically the highest priority SUPAPolicyAction(s) in ASCII sort
          the SUPAPolicyRuleAtomic object and then terminate
      5:  execute all SUPAPolicyActions in prioritized order

                - Numeric identifiers always have lower precedence
                  than non-numeric identifiers
                - A larger set (if
          any) regardless of pre-release fields has a higher
                  precedence than a smaller set, if whether other SUPAPolicyActions
          succeed or fail
      6:  execute 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 SUPAPolicyActions in the following subsections.

5.20.1.1.  The Attribute "supaVersionMajor"

   This is a mandatory string attribute, prioritized order (if
          any) until at least one SUPAPolicyAction fails, and contains then
          terminate

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 2 and 3 MUST execute a string
   representation single SUPAPolicyAction,
   and then terminate execution of an integer that the SUPAECAPolicyRuleAtomic object.
   If the value of supaECAPolActionEvalStrategy is greater than 4, 5 or equal to zero.
   It indicates 6, then all
   SUPAPolicyActions that have a significant increase in functionality is
   present in this version. It MAY also indicate priority will be executed first,
   starting with the SUPAPolicyAction(s) that have the highest
   priority, and then descending in prioritized order. During this version has
   changes
   process, any SUPAPolicyActions that are NOT backwards-compatible; this have the SAME priority MAY be denoted
   executed in
   the supaVersionBuildMetadata class attribute.

   The special string "0.1.0" is for initial development any order. After all SUPAPolicyActions that MUST
   NOT be considered stable. Improvements to this initial version,
   before they are released to the public, have an
   associated priority have executed, then all SUPAPolicyAction(s) that
   do not have a priority 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 then executed (in any backwards incompatible changes order).

   Assume that the actions in a given SUPAPolicyAction are introduced. It MAY
   include minor and patch level changes. The minor and patch version
   numbers MUST be reset to defined
   as follows:

      SUPAPolicyAction A, priority 0 when
      SUPAPolicyAction B, priority 10
      SUPAPolicyAction C, priority 5
      SUPAPolicyAction D, no priority
      SUPAPolicyAction E, no priority

   Then, if the major version number is
   incremented.

5.20.1.2.  The Attribute "supaVersionMinor"

   This is a mandatory string attribute, and contains a string
   representation of supaECAPolActionEvalStrategy attribute value equals:

      0: an integer that error is greater than or equal to zero.
   It indicates that issued
      1: this release contains a set of features and/or
   bug fixes that MUST be backwards-compatible.

   The minor version Y (i.e., x.Y.z, where x > 0) SUPAPolicyAction MUST NOT be incremented
   if new, backwards-compatible changes used (since it is not yet
         properly initialized)
      2: only SUPAPolicyAction A is executed
      3: only SUPAPolicyAction E is executed
      4: only SUPAPolicyAction B is executed
      5: all SUPAPolicyActions are introduced. It MUST be
   incremented if executed, regardless of any features are marked as deprecated. It MAY be
   incremented if new functionality
         failures; the order of execution is B, then C, then A, then
         one of either D or improvements E, then the other of D or E
      6: all SUPAPolicyActions are introduced.
   It MAY include patch level changes. The patch version number MUST
   be reset executed until a failure is
         detected, and then execution for all SUPAPolicyActions
         terminate; the execution order (up to 0 when the minor version number occurrence of the
         failure) is incremented.

5.20.1.3. B, then C, then A, then one of either D or E, then
         the other of D or E

6.5.2.  SUPAECAPolicyRuleAtomic Relationships

   Currently, the SUPAECAPolicyRuleAtomic class does not define any
   relationships.

6.6.  The Attribute "supaVersionPatch" Concrete Class "SUPAECAPolicyRuleComposite"

   This is a mandatory string attribute, concrete class. This class is a type of
   PolicyContainer, and represents a SUPAECAPolicyRule as a hierarchy
   of SUPAPolicy objects, where the hierarchy contains instances of a string
   representation
   SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects.
   Each of the SUPAPolicy objects, including the outermost
   SUPAECAPolicyRuleComposite object, are separately manageable. More
   importantly, each SUPAECAPolicyRuleComposite object represents an integer
   aggregated object that is greater than or equal to zero.
   It indicates that this version contains ONLY bug fixes. itself manageable.

   The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented
   if new, backwards-compatible changes are introduced. A bug fix difference between a SUPAECAPolicyRuleComposite and ability
   SUPAECAPolicyRuleAtomic is
   defined as an internal change that fixes incorrect behavior.

5.20.1.4.  The Attribute "supaVersionPreRelease" each SUPAECAPolicyRuleComposite
   defines its own scope. This is an optional string attribute, and contains a string
   defining means that all instances of the pre-release version.

   A pre-release version MAY be denoted by appending a hyphen
   SUPAECAPolicyRuleAtomic and a
   series SUPAECAPolicyRuleComposite classes
   will execute according to their priorities. This means that the
   priority 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 SUPAECAPolicyRuleComposite object is used to
   determine the associated normal version. A pre-release version
   indicates position that its containing SUPAPolicyActions will
   be executed; the version is unstable and might not satisfy priorities of the
   intended compatibility requirements as denoted contained SUPAPolicyActions are
   then used. Consider the following example:

   +--A (SUPAECAPolicyRuleAtomic), priority 5
   |
   +--B (SUPAECAPolicyRuleAtomic), priority 0
   |
   +--C (SUPAECAPolicyRuleComposite), priority 10
   |  |
   |  +--C1 (SUPAECAPolicyRuleAtomic), priority 2
   |  |
   |  +--C2 (SUPAECAPolicyRuleAtomic), priority 1
   |
   +--D (SUPAECAPolicyRuleAtomic), no priority

   The execution order will be C1, followed by 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. C2, followed by A,
   followed by B, followed by D.

6.6.1.  SUPAECAPolicyRuleComposite Attributes

   Currently, the SUPAECAPolicyRuleComposite class defines one
   attribute, as described in the following subsection.

6.6.1.1.  The Attribute "supaVersionBuildMetadata" "supaECAEvalRuleStrategy"

   This is an optional string attribute, and contains a string defining mandatory, non-zero, integer attribute that enumerates
   a set of allowable alternatives that define how the build metadata. Build metadata MAY be denoted by appending set of
   SUPAPolicyAction object instances in a
   plus sign SUPAECAPolicyRuleComposite
   object are evaluated. It is assumed that the event and a series condition
   clauses of dot-separated identifiers immediately
   following the patch or pre-release version. Identifiers MUST be
   made up of only ASCII alphanumerics SUPAECAPolicyRuleComposite have evaluated to TRUE
   (e.g., the event has occurred and a hyphen. Identifiers
   MUST NOT be empty. Build metadata SHOULD be ignored when determining
   version precedence. Examples the conditions were met).
   Values include: 1.0.0.-alpha+1,
   1.0.0+20130313144700,

      0:  error
      1:  init
      2:  execute the first SUPAPolicyAction in the
          SUPAECAPolicyRuleComposite object and 1.0.0-beta+exp.sha.5114f85.

6.  SUPA ECAPolicyRule Information Model

   This section defines then terminate
      3:  execute the classes, attributes, last SUPAPolicyAction in the
          SUPAECAPolicyRuleComposite object and relationships
   of then terminate
      4:  execute only the SUPA ECAPolicyRule Information Model (EPRIM). Unless
   otherwise stated, highest priority SUPAPolicyAction(s) in
          the SUPAECAPolicyRuleComposite object and then terminate
      5:  execute all SUPAPolicyActions in prioritized order (if
          any) in that particular SUPAECAPolicyRuleComposite object,
          regardless of whether other SUPAPolicyActions succeed or fail
      6:  execute all classes (and attributes) defined SUPAPolicyActions in this
   section were abstracted from DEN-ng [2], prioritized order (if
          any) in that particular SUPAECAPolicyRuleComposite object
          until at least one SUPAPolicyAction fails, and then terminate

   Note that 0 and 1 represent error and initialization states,
   respectively. Values 2 and 3 MUST execute a version single SUPAPolicyAction,
   and then terminate execution of them are all SUPAPolicyActions in this
   SUPAECAPolicyRuleComposite object.

   If the process value of being added to [5].

6.1.  Overview

   Conceptually, the EPRIM supaECAEvalStrategy attribute is 4, 5 or 6, then
   all SUPAPolicyActions that have a set of subclasses priority will be executed first,
   starting with the SUPAPolicyAction(s) that specialize have the
   concepts defined highest
   priority, and then descending in the GPIM for representing the components of a
   Policy prioritized order. During this
   process, any SUPAPolicyActions that uses ECA semantics. This is shown have the SAME priority MAY be
   executed in Figure 23 (only
   new EPRIM subclasses and their GPIM superclasses are shown; note any order. After all SUPAPolicyActions that the SUPAPolicyMetadata hierarchy is used **as is**).

   (Class of another model have an
   associated priority have executed, then all SUPAPolicyAction(s) that SUPA is integrating into)
       |
       +---SUPAPolicyObject (5.2)
             |
             +---SUPAPolicyStructure (5.3)
             |     |
             |     +---SUPAECAPolicyRule (6.4)
             |          |
             |          +---SUPAECAPolicyRuleAtomic (6.5)
             |          |
             |          +---SUPAECAPolicyRuleComposite (6.6)
             |
             +---SUPAPolicyComponentStructure (5.6)
                   |
                   +---SUPAPolicyClause (5.7)
                   |     |
                   |     +---SUPABooleanClause (6.7)
                   |
   do not have a priority are then executed (in any order).

   Assume that a SUPAECAPolicyRuleComposite object contains three
   SUPAECAPolicyRuleAtomic objects as well as one
   SUPAECAPolicyRuleComposite object (that contains two
   SUPAECAPolicyRuleAtomic objects), as shown below.

      Z (SUPAECAPolicyRuleComposite)
      |
      +--A (SUPAECAPolicyRuleAtomic), priority 5
      |          +---SUPAECAPolicyRuleAtomic (6.8)
      +--B (SUPAECAPolicyRuleAtomic), priority 0
      |
      +--C (SUPAECAPolicyRuleComposite), priority 10
      |  |          +---SUPAECAPolicyRuleComposite (6.9)
      |
                   +---SUPAPolicyComponentDecorator (5.9)  +--C1 (SUPAECAPolicyRuleAtomic), priority 2
      |
                         +---SUPAECAComponent(6.10)  |
                               +---SUPAPolicyEvent (6.11)
      |
                               +---SUPAPolicyCondition (6.12)  +--C2 (SUPAECAPolicyRuleAtomic), priority 1
      |
                               +---SUPAPolicyAction (6.13)

              Figure 23.  The EPRIM Class Hierarchy

   Specifically, the EPRIM specializes
      +--D (SUPAECAPolicyRuleAtomic), no priority

   Then, if the SUPAPolicyStructure class
   class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it
   also specializes supaECAEvalStrategy attribute value of Z equals:

      0: an error is issued
      1: all SUPAPolicyActions MUST NOT be used (since their containing
         SUPAECAPolicyRuleComposite object is not properly initialized)
      2: only SUPAPolicyAction A is executed
      3: only SUPAPolicyAction D is executed
      4: two subclasses SUPAPolicyActions are executed: C1, followed by C2
      5: all SUPAPolicyActions are executed, regardless of any
         failures; the SUPAPolicyComponentStructure
   class to create two new sets order of policy components. These two
   SUPAPolicyComponentStructure subclasses are:

      o execution is C1, then C2, then A, then
         B, then D
      6: all SUPAPolicyActions are executed until a new subclass of SUPAPolicyClause, called SUPABooleanClause
        (see sections 6.7 - 6.9), failure is defined
         detected, and then execution for constructing Boolean
        clauses that are specific all SUPAPolicyActions
         terminate; the execution order (up to the needs occurrence of ECA Policy Rules
      o the
         failure) is C1, then C2, then A, then B, then D

   Note that the supaECAEvalRuleStrategy defines the same semantics as
   the supaECAPolActionEvalStrategy. The difference is that the former
   is applied to a new subclass SUPAECAPolicyRuleComposite object, and the latter is
   applied to a SUPAECAPolicyRuleAtomic object.

6.6.2.  SUPAECAPolicyRuleComposite Relationships

   Currently, the SUPAECAPolicyRuleComposite defines a single
   aggregation between it and SUPAECAPolicyRule, as described below.

6.6.2.1.  The Aggregation "SUPAHasECAPolicyRule"

   This is an optional aggregation that implements the composite
   pattern. The multiplicity of this aggregation is 0..1 on the
   aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part
   (SUPAECAPolicyRule) side. This means that if this aggregation
   is defined, then at least one SUPAECAPolicyRule object (which may
   be either an instance of SUPAPolicyComponentDecorator, called
        SUPAECAComponent (see sections 6.10 - 6.13), is defined for
        constructing reusable objects that represent Events,
        Conditions, a SUPAECAPolicyRuleAtomic or a
   SUPAECAPolicyRuleComposite class) must also be instantiated and Actions
   aggregated by this particular SUPAECAPolicyRuleComposite object.
   The EPRIM provides new functionality, based on the GPIM, semantics of this aggregation are defined by
   extending the GPIM to define new classes and relationships.
   SUPAHasECAPolicyRuleDetail association class.

6.6.2.2.  The
   EPRIM does NOT define new classes that are not inherited from
   existing GPIM classes. Association Class "SUPAHasECAPolicyRuleDetail"

   This ensures that is an optional concrete association class, and defines the
   semantics of the GPIM
   are not changed, even though new functionality (for ECA Policy
   Rules SUPHasECAPolicyRule aggregation. This enables the
   attributes and components) are being defined. relationships of the SUPAHasECAPolicyRuleDetail
   class to be used to constrain which SUPAECAPolicyRule objects
   can be aggregated by this particular SUPAECAPolicyRuleComposite
   object instance. It contains a single attribute, defined below.

6.6.2.2.1.  The overall strategy for refining Attribute "supaECAPolicyIsDefault"

   This is an optional Boolean attribute. If the GPIM value of this
   attribute is as follows:

      o true, then this SUPAECAPolicyRule is defined as a subclass of the GPIM
        SUPAPolicyStructure class
      o A SUPAECAPolicyRule has event, condition, default
   policy, and action clauses
        o Conceptually, this can will be viewed as three aggregations
          between the executed if no other SUPAECAPolicyRule
   in the SUPAECAPolicyRuleComposite container has been executed.
   This is a convenient way for error handling, though care should
   be taken to ensure that only one default policy rule is defined
   per SUPAECAPolicyRuleComposite container.

6.7.  The Abstract Class "SUPABooleanClause"

   A SUPABooleanClause specializes a SUPAPolicyClause, and each clause
        o Each aggregation uses an instance defines
   a Boolean expression consisting of a concrete subclass standard structure in the
   form of
          SUPAPolicyClause; a SUPAPolicyVariable, a SUPAPolicyOperator, and a
   SUPAPolicyValue. For example, this can enables the following Boolean
   clause to be defined:

      Foo >= Baz

   where 'Foo' is a SUPABooleanClause
          (making it ECA-specific), PolicyVariable, '>=' is a SUPAEncodedClause (making it
          generic in nature), or PolicyOperator, and
   'Baz' is a new PolicyValue.

   Note that in this approach, the SUPAPolicyVariable and
   SUPAPolicyValue terms are defined as an appropriate subclass of SUPAPolicyClause
        o Concrete subclasses
   the SUPAPolicyComponentDecorator class; it is assumed that the
   SUPAPolicyOperator is an instance of SUPAPolicyClause may be decorated the SUPAPolicyOperator class.
   This enables the EPRIM, in conjunction with zero or more concrete subclasses of the
          SUPAPolicyComponentDecorator GPIM, to be used
   as a reusable class
      o An optional set library. This encourages interoperability,
   since each element of GPIM SUPAPolicySource objects can be the clause is itself an object defined to represent by
   the authoring of a SUPAECAPolicyRule
      o  SUPA object hierarchy.

   An optional set of GPIM SUPAPolicyTarget objects can entire SUPABooleanClause may be
        defined to represent negated by setting the set
   supaBoolClauseIsNegated class attribute of managed entities that will be
        affected by this SUPAECAPolicyRule
      o An optional set the SUPABooleanClause
   class to TRUE. Individual terms of SUPAPolicyMetadata a Boolean clause can be defined for any
        of negated
   by using the objects that make up a SUPAECAPolicyRule, including
        any of its components

6.2.  Constructing a SUPAECAPolicyRule

   There are several different ways to construct a SUPAECAPolicyRule;
   they differ supaTermIsNegated Boolean attribute in which set of components are used to define the
   content
   SUPAPolicyTerm class (see section 5.10).

   A PolicyClause is in Conjunctive Normal Form (CNF) if it is a
   sequence of the SUPAECAPolicyRule, and whether logically ANDed terms, where each component term is
   decorated or not. The following are some examples a sequence
   of creating logically ORed terms. A PolicyClause is in Disjunctive Normal
   Form (DNF) if it is a
   SUPAECAPolicyRule:

      o Define three types sequence of SUPABooleanClauses, one logically ORed terms, where each for the
        event, condition, and action clauses that make up
   term is a
        SUPAECAPolicyRule
        o For one or more sequence of the above clauses, associate an
          appropriate set logically ANDed terms.

   The construction of SUPAPolicyEvent, SUPAPolicyCondition, or
          SUPAPolicyAction objects, and complete the clause using an
          appropriate SUPAPolicyOperator and a corresponding
          SUPAPolicyValue or SUPAPolicyVariable
        o Note that compound Boolean clauses may be formed using
          one or more SUPABooleanClauseComposite objects with one or more SUPABooleanClauseAtomic objects
        o Define a SUPAPolicyCollection component, complex clauses, which is used to
          aggregate consist of a set
   of objects appropriate for a clause, and
          complete simple clauses in CNF or DNF (as shown in the clause above example),
   is provided by using an appropriate SUPAPolicyOperator
          and a corresponding SUPAPolicyValue or SUPAPolicyVariable
      o Create a new the composite pattern [3] to construct two
   concrete subclass of SUPAPolicyComponentStructure
        (i.e., a sibling class subclasses of SUPAPolicyComponentDecorator the abstract SUPABooleanClause class. These
   are called SUPABooleanClauseAtomic and
        SUPAPolicyClause), SUPABooleanClauseComposite,
   and use this new subclass are defined in a concrete
        subclass of SUPABooleanClause; note that this approach sections 6.8 and 6.9, respectively. This
   enables
        the new concrete subclass instances of SUPAPolicyComponentStructure either a SUPABooleanClauseAtomic and/or a
   SUPABooleanClauseComposite to
        optionally be decorated as well
      o Create aggregated into a new subclass of SUPAPolicyComponentDecorator (e.g.,
   SUPABooleanClauseComposite object.

6.7.1.  SUPABooleanClause Attributes

   The SUPABooleanClause class currently defines three attributes,
   which are defined in the following subsections.

6.7.1.1.  The Attribute "supaBoolClauseBindValue"

   This is a sibling of SUPAECAComponent) that provides ECA-specific
        functionality, mandatory non-zero integer attribute, and use that defines the
   order in which terms bind to decorate a SUPAPolicyClause
      o Create a new concrete subclass of SUPAPolicyStructure that
        provides ECA-specific functionality, clause. For example, the Boolean
   expression "((A AND B) OR (C AND NOT (D OR E)))" has the following
   binding order: terms A and define all or part
        of its content by aggregating B have a set bind value of SUPAPolicyClauses

6.3.  Working With SUPAECAPolicyRules

   A SUPAECAPolicyRule is 1; term C has a type
   binding value of SUPAPolicy. It is a tuple that
   MUST 2, and terms D and E have three clauses, defined as follows:

      o The event clause defines a binding value of 3.

6.7.1.2.  The Attribute "supaBoolClauseIsCNF"

   This is an optional Boolean expression that, if TRUE,
        triggers attribute. If the evaluation value of its condition clause (if the
        event clause this
   attribute is not TRUE, then no further action for this
        policy rule takes place).
      o SUPABooleanClauseComposite is in CNF
   form. Otherwise, it is in DNF form.

6.7.1.3.  The condition clause defines Attribute "supaBoolClauseIsNegated"

   This is a mandatory Boolean expression that, if
        TRUE, enables the actions in the action clause to be executed
        (if attribute. If the condition clause value of this
   attribute is not TRUE, then no further action
        for this policy rule takes place).
      o The action clause contains a set of actions (note that an
        action MAY invoke another SUPAECAPolicyRule; see section
        6.13).

   Each of the above clauses can be a simple Boolean expression (of
   the form {variable operator value}, or a compound Boolean
   expression consisting of Boolean combinations of clauses.
   Compound Boolean expressions SHOULD be in CNF or DNF. (entire) SUPABooleanClause is
   negated. Note that each the supaPolTermIsNegated class attribute of
   the above three clauses MAY have SUPAPolicyTerm class is used to negate a set of
   SUPAPolicyMetadata objects single term.

6.7.2.  SUPABooleanClause Relationships

   Currently, no relationships are defined for this class.

6.8.  The Concrete Class "SUPABooleanClauseAtomic"

   This is a mandatory concrete class that can constrain, or otherwise
   affect, how represents a
   SUPABooleanClause that clause is treated. For example, can operate as a single, stand-alone,
   manageable object. A SUPABooleanClauseAtomic object can NOT be
   modeled as a set of
   SUPAPolicyMetadata MAY affect whether none, some, or all actions
   are executed, and what happens hierarchical clauses; if an action fails.

   Each this functionality is
   required, then a SUPABooleanClauseComposite object must be used.
   Examples of the three Boolean clauses that could be contained in a
   SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P
   and Q are literals (e.g., a variable name that can be constructed from either a
   SUPAEncodedClause true
   or false, or a SUPABooleanClause. The advantage of using
   SUPAEncodedClauses is simplicity, as the content formula that evaluates to a literal). Examples of the clause is
   encoded directly into the
   Boolean clauses that are NOT in CNF are NOT(P AND Q),
   (P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent
   forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and
   P AND (Q OR S) AND (Q OR S), respectively.

6.8.1.  SUPABooleanClauseAtomic Attributes

   No attributes of the SUPAEncodedClause. are currently defined for this class.

6.8.2.  SUPABooleanClauseAtomic Relationships

   Currently, no relationships are defined for this class.

6.9.  The
   advantage of using SUPABooleanClauses is reusability, since each
   term in each clause Concrete Class "SUPABooleanClauseComposite"

   This is potentially a reusable object.

   Since mandatory concrete class that represents a
   SUPABooleanClause is that can operate as a subclass hierarchy of a
   SUPAPolicyClause
   (see Section 6.7), it can be decorated by one or more concrete
   subclasses objects, where the hierarchy contains instances of
   SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite
   objects. Each of SUPAPolicyComponentDecorator. Therefore, a
   SUPAECAPolicyRule can be built entirely from objects defined in the GPIM SUPABooleanClauseAtomic and EPRIM, which facilitates
   SUPABooleanClauseComposite objects, including the construction outermost
   SUPABooleanClauseComposite object, are separately manageable.
   More importantly, each SUPABooleanClauseComposite object
   represents an aggregated object that is itself manageable.

   Examples of
   SUPAPolicies by a machine.

   The relation between Boolean clauses that could be contained in a SUPAECAPolicyRule
   SUPABooleanClauseComposite object include ((P OR Q) AND R), and
   ((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, and
   T are literals.

6.9.1.  SUPABooleanClauseComposite Attributes

   No attributes are currently defined for this class.

6.9.2.  SUPABooleanClauseComposite Relationships

   Currently, the SUPABooleanClauseComposite class defines a SUPAPolicyClause single
   aggregation, which is shown described in Figure 24, and the following subsection.

6.9.2.1.  The Aggregation "SUPAHasBooleanClause"

   This is explained in further detail in
   Section 6.4.

                        SUPAHasPolicyClause
              +----------------+------------------------+
              |                ^                        |
              |                |                        |
             / \               |                        |
              A                |                        |
    A        \ / 0..1          |             A    1..n \ /
   +----------+-----------+    |            +-----------+------+
   |  SUPAPolicyStructure |    |            | SUPAPolicyClause |
   +----------+-----------+    |            +-----------+------+
             / \               |                       / \
              I      A         |                        |
              I     +----------+----------------+       |
              I     | SUPAHasPolicyClauseDetail |       |
              I     +---------------------------+       |
              I                                         |
    C         I                                 A       |
   +----------+----------+                     +--------+----------+
   |  SUPAECAPolicyRule  |                     | a mandatory aggregation that defines the set of
   SUPABooleanClause |
   +---------------------+                     +-------------------+

                Figure 24.  SUPAECAPolicyRule Clauses objects that are aggregated by this
   SUPABooleanClauseComposite object.

   The SUPAHasPolicyClause multiplicity of this relationship is 0..1 on the aggregate
   (SUPABooleanClauseComposite) side, and 1..n on the part
   (SUPABooleanClause) side. This means that one or more
   SUPABooleanClauses are aggregated and used to define this
   SUPABooleanClauseComposite object. The 0..1 cardinality on the
   SUPABooleanClauseComposite side is necessary to enable
   SUPABooleanClauses to exist (e.g., in a PolicyRepository) before
   they are used by a SUPABooleanClauseComposite. The semantics of
   this aggregation is implemented using defined by the
   SUPAHasPolicyClauseDetail SUPAHasBooleanClauseDetail
   association class. These were
   described in sections 5.4.2.1 and 5.4.2.2, respectively.

6.4.

6.9.2.2.  The Abstract Association Class "SUPAECAPolicyRule" "SUPAHasBooleanClauseDetail"

   This is a mandatory abstract class, concrete association class that defines the
   semantics of the SUPAHasBooleanClause aggregation. This enables the
   attributes and relationships of the SUPAHasBooleanClauseDetail
   class to be used to constrain which SUPABooleanClause objects
   can be aggregated by this particular SUPABooleanClauseComposite
   object instance.

6.9.2.2.1.  The Attribute "supaIsHornClause"

   This is a PolicyContainer
   that aggregates PolicyEvents, PolicyConditions, PolicyActions into
   a an optional attribute of type Boolean. If the value of policy rule known as an Event-Condition-Action (ECA)
   policy rule. As previously explained, this
   attribute is TRUE, then this SUPABooleanClause is a Horn clause.
   This has the following
   semantics:

      IF the event important properties for logic programming and model
   theory. For example, a Horn clause evaluates is able to TRUE
         IF the condition clause evaluates express implication
   of one variable from a set of other variables.

6.10.  The Abstract Class "SUPAECAComponent"

   This is a mandatory abstract class that defines three concrete
   subclasses, one each to TRUE
            THEN execute actions in represent the action clause
         ENDIF
      ENDIF concepts of reusable events,
   conditions, and actions. They are called SUPAPolicyEvent,
   SUPAPolicyCondition, and SUPAPolicyAction, respectively.

   SUPAECAComponents provide two different ways to construct
   SUPAPolicyClauses. The event clause, condition clause, first is for the SUPAECAComponent to be
   used as either a SUPAPolicyVariable or a SUPAPolicyValue, and action the
   second is for the SUPAECAComponent to contain the entire clause collectively
   form
   text.

   For example, suppose it is desired to define a three-tuple. Each policy condition
   clause MUST be defined by at least one
   SUPAPolicyClause (which MAY be decorated with other elements, the text 'queueDepth > 10'. Two approaches could
   satisfy this as described in section 5.7).

   Each of follows:

   Approach #1 (canonical form):
      SUPAPolicyCondition.supaPolicyConditionData contains the three types of clauses text
        'queueDepth'
      SUPAPolicyOperator.supaPolOpType is a 3-tuple of set to '1' (greater than)
      SUPAPolicyValue.supaPolValContent is set to '10'

   Approach #2 (SUPAECAComponent represents the form:

      {variable operator value}

   Each of entire clause):
      SUPAPolicyCondition.supaPolicyConditionData contains the three clauses MAY be combined with additional clauses
   using any combination text
        'queueDepth > 10'

   The class attribute supaECACompIsTerm, defined in subsection
   6.10.1.1, is used to identify which of these two approaches is
   used by an object instance of logical AND, OR, and NOT operators; this
   forms a "compound" Boolean clause. For example, if A, B, class.

6.10.1.  SUPAECAComponent Attributes

   A single attribute is currently defined for this class, and C are
   three attributes is
   described in the following subsection.

6.10.1.1.  The Attribute "supaECACompIsTerm"

   This is an event, optional Boolean attribute. If the value of this
   attribute is TRUE, then a valid event clause could be:

      (A AND B) OR C

   Note that this SUPAECAComponent is used as the above expression value
   of a SUPAPolicyTerm to construct a SUPAPolicyClause (this is
   approach #1 in DNF; section 6.10 above). If the equivalent CNF form value of this attribute
   is ((A OR C) AND (B OR C)). In either case, FALSE, then this SUPAECAComponent contains the output text of all
   three clauses the
   entire corresponding SUPAPolicyClause (this is either TRUE or FALSE; this facilitates combining
   and chaining SUPAECAPolicyRules.

   An action clause MAY invoke a new SUPAECAPolicyRule; see approach #2 in
   section
   6.13 6.10 above).

6.10.2.  SUPAECAComponent Relationships

   No relationships are currently defined for more details.

   An ECAPolicyRule MAY be optionally augmented with PolicySources
   and/or PolicyTargets (see sections 5.16 and 5.17, respectively).
   In addition, all objects that make up this class.

6.11.  The Concrete Class "SUPAPolicyEvent"

   This is a SUPAECAPolicyRule MAY
   have SUPAPolicyMetadata (see section 5.16) attached mandatory concrete class that represents the concept of
   an Event that is applicable to them a policy management system. Such
   an Event is defined as anything of importance to
   further describe the management
   system (e.g., a change in the system being managed and/or specify behavior.

   When its
   environment) occuring on a time-axis (as defined in an information model, each [19]).

   It should be noted that instances of this class are not themselves
   events. Rather, instances of this class appear in SUPAPolicyClauses
   to describe what types of events the event, condition,
   and action clauses MUST SUPAPolicy is triggered by
   and/or uses.

   SUPAPolicyEvents can be represented used as an aggregation between a
   SUPAECAPolicyRule (the aggregate) and a set part of event, condition,
   or action objects (the components). However, a data model MAY map
   these definitions to a more efficient form (e.g., SUPAPolicyClause; this
   is done by flattening
   these three types specifying the attribute name and value of object instances, along with their respective
   aggregations, into a single object instance).

   The composite pattern [3] is applied to an Event in
   the SUPAECAPolicyRule
   class, enabling its (concrete) subclasses supaPolicyEventData attribute of the SUPAPolicyEvent. This
   enables event attributes to be used as either a
   stand-alone policy rule or as a hierarchy part of policy rules.
   SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both
   inherit a SUPAPolicyClause.

   Information from SUPAECAPolicyRule. This means events that they are both
   a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule
   aggregation enables a particular SUPAECAPolicyRuleComposite
   object trigger SUPAPolicies need to aggregate both SUPAECAPolicyRuleComposite be made
   available for use in condition and action clauses, as well as
   SUPAECAPolicyRuleAtomic
   inappropriate decorator objects. In contrast, a
   SUPAECAPolicyRuleAtomic Subclasses (such as one for using
   YANG notifications as policy events) need to define how the
   iformation from the environment or event is used to populate
   variables that can NOT aggregate either a
   SUPAECAPolicyRuleComposite be used by decorator, condition, or a SUPAECAPolicyRuleAtomic.
   SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite
   action objects.

6.11.1.  SUPAPolicyEvent Attributes

   Currently, five attributes are defined for the SUPAPolicyEvent
   class, which are described in sections 6.5 and 6.6, respectively. the following subsections.

6.11.1.1.  The Attribute "supaPolicyEventData[1..n]"

   This is
   shown in Figure 25.

                               A
                         1..n +-------------------+
                             \|                   |
             +--------------- + SUPAECAPolicyRule |
             |               /|                   |
             |                +--------+----------+
             |                        / \
             | SUPAHasECAPolicyRule    I
             |                         I
             |                         I
             |                         I
             |         +---------------+-------------+
             |         I                             I
            / \        I                             I
             A         I                             I
        C   \ / 0..1   I                  C          I
       +-----+---------+----------+      +-----------+-----------+
       |SUPAECAPolicyRuleComposite|      |SUPAECAPolicyRuleAtomic|
       +--------------------------+      +-----------------------+

   Figure 25.  The Composite Pattern Applied to a SUPAECAPolicyRule

   Note mandatory attribute that defines an array of strings.
   Each string in the HasSUPAECAPolicyRule aggregation array represents an attribute name and value
   of an Event object. The format of each string is defined by as
   name:value. The 'name' part is the
   HasSUPAECAPolicyRuleDetail association class; both are defined
   in sections 6.6.2 and 6.6.3, respectively.

6.4.1.  SUPAECAPolicyRule Attributes

   Currently, name of the SUPAECAPolicyRule defines two attributes, as
   described in SUPAPolicyEvent
   attribute, and the following subsections.

6.4.1.1.  The Attribute "supaECAPolicyRulePriority"

   This 'value' part is a mandatory non-negative integer attribute that defines the priority value of that attribute.

   Note: [1..n] means that this particular SUPAECAPolicyRule. A larger value
   indicates is a higher priority. A default multi-valued property that has
   at least one (and possibly more) attributes. For example, if
   this value of 0 MAY be assigned.

   Priority is used primarily for 2 reasons: (1) this attribute is:

      {(startTime:0800), (endTime:1700), (date:2016-05-11),
       (timeZone:-08:00)}

   then this attribute contains four properties, called startTime,
   endTime, date, and timeZone, whose values are 0800, 1700, May 11
   2016, and Pacific Standard Time, respectively.

   This attribute works with another class attribute, called
   supaPolicyEventEncoding, which defines how to resolve conflicts
   among policy actions (e.g., given interpret this
   attribute. These two attributes form a set of conflicting actions,
   which one will execute) tuple, and (2) together enable
   a machine to define understand the execution order syntax and value of
   policy actions (e.g., when one action may depend on the output data carried
   by the object instance of
   one or more previous actions).

6.4.1.2. this class.

6.11.1.2.  The Attribute "supaECAPolicyRuleStatus" "supaPolicyEventEncoding"

   This is an optional non-negative a mandatory non-zero enumerated integer whose value attribute, and
   defines how to interpret the current status supaPolicyEventData class attribute.
   These two attributes form a tuple, and together enable a machine
   to understand the syntax and value of the data carried by the
   object instance of this policy rule. class. Values include:

      0:  error
      1:  init
      2:  In development, not ready to be deployed
     1:  Ready to be deployed
     2:  Deployed but not enabled  String
      3:  Deployed and enabled, but not executed  Integer
      4:  Executed without errors  Boolean
      5:  Executed with errors  Floating Point
      6:  Aborted during execution

   Note that  DateTime
      7:  Object referenced by GUID
      8:  Object referenced by URI
      9:  Object referenced by FQDN
     10:  Object referenced by FQPN
     11:  Object referenced by string_instance_id

   Enumerations 0 and 1 represent signify an error state and an initialization states,
   state, respectively.

6.4.2.  SUPAECAPolicyRule Relationships

   Currently, Enumerations 2-6 define fundamental data types;
   for example, the SUPAECAPolicyRule does not event payload could carry such a value. The final
   five enumerations define any
   relationships. It inherits all four relationships defined an object reference. The value 11 defines
   the canonical representation, in ASCII, of an instance ID of
   this object.

6.11.1.3.  The Attribute "supaPolicyEventIsPreProcessed"

   This is an optional Boolean attribute. If the value of this
   attribute is TRUE, then this SUPAPolicyEvent has been pre-
   processed by an external entity, such as an Event Service Bus,
   before it was received by the SUPAPolicyStructure class (see section 5.3.2.).

6.5. Policy Management System.

6.11.1.4.  The Concrete Class "SUPAECAPolicyRuleAtomic" Attribute "supaPolicyEventIsSynthetic"

   This is a mandatory concrete class. an optional Boolean attribute. If the value of this
   attribute is TRUE, then this SUPAPolicyEvent has been produced by
   the Policy Management System. If the value of this attribute is
   FALSE, then this SUPAPolicyEvent has been produced by an entity
   in the system being managed.

6.11.1.5.  The Attribute "supaPolicyEventTopic[0..n]"

   This class is a type mandatory array of
   PolicyContainer, string attributes, and represents a SUPAECAPolicyRule contains the
   subject that this PolicyEvent describes.

   Note: [0..n] means that can
   operate as a single, stand-alone, manageable object. Put another
   way, a SUPAECAPolicyRuleAtomic object can NOT be modeled as a set
   of hierarchical SUPAECAPolicyRule objects; if this is required,
   then a SUPAECAPolicyRuleComposite object should be used instead.

6.5.1.  SUPAECAPolicyRuleAtomic Attributes

   Currently, the SUPAECAPolicyRuleAtomic class does not define any multi-valued property that has
   zero or more attributes.

6.5.2.  SUPAECAPolicyRuleAtomic

6.11.2.  SUPAPolicyEvent Relationships

   Currently, the SUPAECAPolicyRuleAtomic class does not define any
   relationships. It inherits all four

   No relationships are currently defined by the
   SUPAPolicyStructure class (see section 5.3.2.).

6.6. for this class.

6.12.  The Concrete Class "SUPAECAPolicyRuleComposite" "SUPAPolicyCondition"

   This is a mandatory concrete class. This class is a type of
   PolicyContainer, and that represents a SUPAECAPolicyRule as a hierarchy
   of SUPAPolicy objects, where the hierarchy contains instances of a
   SUPAECAPolicyRuleAtomic and/or SUPAECAPolicyRuleComposite objects.
   Each concept of the SUPAPolicy objects, including the outermost
   SUPAECAPolicyRuleComposite object, are separately manageable. More
   importantly, each SUPAECAPolicyRuleComposite object represents
   an
   aggregated object Condition that is itself manageable.

6.6.1.  SUPAECAPolicyRuleComposite Attributes

   Currently, the SUPAECAPolicyRuleComposite defines one attribute,
   as described in will determine whether or not the following subsection.

6.6.1.1.  The Attribute "supaECAEvalStrategy"

   This is a mandatory, non-zero, integer attribute that enumerates
   a set of allowable alternatives that define how Actions
   in the set of SUPAECAPolicyRule object instances in a SUPAECAPolicyRuleComposite
   object to which it belongs are evaluated. It is assumed that the event and condition executed or not.

   Condition clauses of the SUPAECAPolicyRules have evaluated needs to TRUE (e.g., the
   event has occurred and be able to access information fromhe
   the conditions were met). Values include:

      0:  error
      1:  init
      2:  execute policy environment (e.g., the first SUPAECAPolicyRule in network element or policy engine
   applying the
          SUPAECAPolicyRuleComposite and then terminate
      3:  execute only policy) or the highest priority SUPAECAPolicyRule(s) in triggering event. This may be done
   using SUPAPolicyVariable objects as decorators. If the SUPAECAPolicyRuleComposite and then terminate
      4:  execute all SUPAECAPolicyRules in prioritized order (if
          any) regardless subclass of whether their SUPAPolicyActions
          succeed or fail
      5:  execute all SUPAECAPolicyRules in prioritized order (if
          any) until at least one SUPAPolicyAction in
   a
          SUPAECAPolicyRule fails, and then terminate

   Note that 0 and 1 represent error and initialization states,
   respectively.

   If SUPAPolicyCondition uses some other encoding, the value definition of supaECAEvalStrategy is 3 or 4, then all
   SUPAECAPolicyRules
   that have a priority class needs to indicate how information from the environment
   or event will be executed first
   (starting with the SUPAECAPolicyRule(s) that have the highest
   priority, and descending); all SUPAECAPolicyRule(s) that do not
   have used.

   SUPAPolicyConditions can be used as part of a priority are then executed (in any order).

   Assume SUPAPolicyClause
   (e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or as a
   standalone SUPAPolicyClause (e.g., the supaPolicyConditionData
   attribute contains text that defines the actions in a given SUPAECAPolicyRuleComposite
   are entire condition clause).
   This is defined as follows

      SUPAECAPolicyRule A, priority 0
      SUPAECAPolicyRule B, priority 10
      SUPAECAPolicyRule C, priority 5
      SUPAECAPolicyRule D, priority 10
      SUPAECAPolicyRule E, priority 2

   Then, if in the supaECAEvalStrategy supaECACompIsTerm attribute value equals:

      0: an error is issued
      1: this SUPAECAPolicyRule MUST NOT be used (since it is not yet
         properly initialized)
      2: only SUPAECAPolicyRule A is executed
      3: only SUPAECAPolicyRules B and D are executed
      4: all SUPAECAPolicyRules are executed, regardless of any
         failures in their SUPAPolicyActions
      5: all SUPAECAPolicyRules the
   SUPAECAComponent class (see section 6.10).

6.12.1.  SUPAPolicyCondition Attributes

   Currently, two attributes are executed until a failure is
         detected, and then execution defined for all SUPAECAPolicyRules
         terminates

6.6.2.  SUPAECAPolicyRuleComposite Relationships

   Currently, the SUPAECAPolicyRuleComposite defines a single
   aggregation between it and SUPAECAPolicyRule, as SUPAPolicyCondition
   class, which are described below.

6.6.2.1. in the following subsections.

6.12.1.1.  The Aggregation "SUPAHasECAPolicyRule" Attribute "supaPolicyConditionData[1..n]"

   This is an optional aggregation a mandatory array of string attributes that implements contains the composite
   pattern. The multiplicity
   content of this aggregation is 0..1 on the
   aggregate (SUPAECAPolicyRuleComposite) side and 1..n on the part
   (SUPAECAPolicyRule) side. This SUPAPolicyCondition object.

   Note: [1..n] means that if this aggregation is defined, then a multi-valued property that has
   at least one SUPAECAPolicyRule object (which may
   be either an instance of a SUPAECAPolicyRuleAtomic or a
   SUPAECAPolicyRuleComposite class) must (and possibly more) attributes.

   If this class is instantiated, then this attribute SHOULD also be instantiated
   instantiated, and
   aggregated by this particular SUPAECAPolicyRuleComposite object.
   The semantics SHOULD be part of this aggregation are defined by the
   SUPAHasECAPolicyRuleDetail association class.

6.6.3. a conformant implementation.

6.12.1.2.  The Association Class "SUPAHasECAPolicyRuleDetail" Attribute "supaPolicyConditionEncoding"

   This is an optional concrete association class, a mandatory non-zero enumerated integer attribute, and
   defines the
   semantics data type of the SUPHasECAPolicyRule aggregation. This enables the supaPolicyConditionData attribute.
   These two attributes form a tuple, and relationships together enable a machine
   to understand the syntax and value of the SUPAHasECAPolicyRuleDetail
   class to be used to constrain which SUPHasECAPolicyRule objects
   can be aggregated by content of this particular SUPAECAPolicyRuleComposite
   object instance.

6.6.3.1.  The Attribute "supaECAPolicyIsDefault"

   This is
   SUPAPolicyCondition object. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text

   Enumerations 0 and 1 signify an optional Boolean attribute. If error state and an initialization
   state, respectively. Enumerations 2-4 are dedicated to OCL (with
   OCL 2.4 being the value latest version as of this
   attribute is true, then this SUPAECAPolicyRule is writing). QVT defines a default
   policy,
   set of languages [20] (the two most powerful and will be executed if no other SUPAECAPolicyRule
   in the SUPAECAPolicyRuleComposite container has been executed.
   This useful are defined
   by enumerations 5 and 6). Alloy is a convenient way language for error handling, though care should
   be taken describing
   constraints, and uses a SAT solver to ensure that only one default policy rule guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but is included for completeness.

   If this class is instantiated, then this attribute SHOULD also be
   instantiated, and SHOULD be part of a conformant implementation.

6.12.2.  SUPAPolicyCondition Relationships

   No relationships are currently defined
   per SUPAECAPolicyRuleComposite container.

6.7. for this class.

6.13.  The Abstract Concrete Class "SUPABooleanClause"

   A SUPABooleanClause specializes a SUPAPolicyClause, and defines
   a Boolean expression consisting of "SUPAPolicyAction"

   This is a standard structure in mandatory concrete class that represents the
   form concept of
   an Action, which is a SUPAPolicyVariable, part of a SUPAPolicyOperator, SUPAECAPolicyRule. The Action MAY be
   executed when both the event and the condition clauses of its
   owning SUPAECAPolicyRule evaluate to true.

   Action clauses needs to be able to access information fromhe
   the policy environment (e.g., the network element or policy engine
   applying the policy) or the triggering event. This may be done
   using SUPAPolicyVariable objects as decorators. If the subclass of
   a
   SUPAPolicyValue. For example, this enables SUPAPolicyAction uses some other encoding, the following Boolean
   clause definition of
   that class needs to indicate how information from the environment
   or event will be defined:

      Foo >= Baz

   where 'Foo' used.

   The execution of this action is determined by its SUPAPolicy
   container, and any applicable SUPAPolicyMetadata objects.
   SUPAPolicyActions can be used in three different ways:

      o as part of a PolicyVariable, '>=' is SUPAPolicyClause (e.g.,
        var = SUPAPolicyAction.supaPolicyActionData)
      o as a PolicyOperator, and
   'Baz' is standalone SUPAPolicyClause (e.g., the
        supaPolicyActionData attribute contains text that defines
        the entire action clause)
      o to invoke one or more SUPAPolicyActions in a PolicyValue. different
        SUPAECAPolicyRule

   In the third case, the execution semantics should not be affected,
   since all SUPAPolicyActions are reusable objects. Note that in this approach, the SUPAPolicyVariable and
   SUPAPolicyValue terms are defined as an appropriate subclass of
   the SUPAPolicyComponentDecorator class; it is assumed
   NOT invoking a different SUPAECAPolicyRule, but rather, invoking a
   SUPAPolicyAction that the
   SUPAPolicyOperator is an instance of the SUPAPolicyOperator class.

   This enables the EPRIM, contained in conjunction with the GPIM, to be used a different SUPAECAPolicyRule.

6.13.1.  Restrictions about SUPAPolicyActions Calling SUPAPolicies

   There was confusion as to whether a reusable class library. This encourages interoperability,
   since each SUPAPolicyAction could call a
   SUPAPolicy or not. While this appears attractive, it presents
   several difficult conceptual problems concerning what element of the clause is itself an object defined by
   the  SUPA object hierarchy.

   An entire SUPABooleanClause may be negated by setting the
   supaBoolClauseIsNegated class attribute of has
   the SUPABooleanClause
   class to TRUE. Individual terms scope of a Boolean clause can be negated
   by using the supaTermIsNegated Boolean attribute control. These problems are not solved in [RFC3460].
   Consider the
   SUPAPolicyTerm class (see section 5.10). following scenario:

      o Policy A PolicyClause is in Conjunctive Normal Form (CNF) if it currently executing
      o Action A1 executes successfully
      o Action A2 calls Policy B
      o Action A3 is a
   sequence of logically ANDed terms, where each term either waiting to execute, or is a sequence
   of logically ORed terms.

   A PolicyClause executing

   When Policy B is in Disjunctive Normal Form (DNF) if called, it is a
   sequence of logically ORed terms, where each term is a sequence
   of logically ANDed terms.

   The construction presumably should execute under the
   scope of more complex clauses, which consist control of a set Policy A (since Policy A has not finished
   executing). However, calling another **ECAPolicyRule** means that
   now, the event clause of simple clauses in CNF or DNF (as shown in Policy B should be activated. It is very
   difficult to ensure that the above example), next thing the Policy Engine does is provided by using
   determine if the composite pattern [3] to construct two
   concrete subclasses event clause of B is satisfied or not.

   Furthermore, what happens to Action A3? Is Policy B supposed to
   finish execution before Action A3? This requires additional logic
   (priorities do not work here!), which requires communication
   between the abstract SUPABooleanClause class. These
   are called SUPABooleanClauseAtomic policy engine and SUPABooleanClauseComposite, both Policies A and B.

   Even if these problems are defined in sections 6.8 solved, what happens if Action A3 fails,
   and 6.9, respectively. This
   enables instances of either the supaPolExecFailStrategy has a SUPABooleanClauseAtomic and/or value of 2 (i.e., if an
   action fails, then a
   SUPABooleanClauseComposite to rollback must be aggregated into performed)? Does Policy BCP
   also get rolled back?

   Therefore, for this version of SUPA, a
   SUPABooleanClauseComposite object.

6.7.1.  SUPABooleanClause SUPAPolicyAction can only
   call another SUPAPolicyAction.

6.13.2.  SUPAPolicyAction Attributes

   The SUPABooleanClause class currently defines one attribute,
   which

   Currently, two attributes are defined for the SUPAPolicyCondition
   class, which are described in the following subsections.

6.7.1.1.

6.13.2.1.  The Attribute "supaBoolClauseIsNegated" "supaPolicyActionData[1..n]"

   This is a mandatory Boolean attribute. If the value array of this
   attribute is TRUE, then this (entire) SUPABooleanClause is
   negated. Note string attributes that contains the supaPolTermIsNegated class attribute of
   the SUPAPolicyTerm class is used to negate a single term.

6.7.2.  SUPABooleanClause Relationships

   Currently, no relationships are defined for the SUPABooleanClause
   class. It inherits the relationships
   content of SUPAPolicyClause (see
   section 5.5.).

6.8.  The Concrete Class "SUPABooleanClauseAtomic" this SUPAPolicyAction object. This is a mandatory concrete attribute works with
   another class that represents attribute, called supaPolicyActionEncoding, which
   defines how to interpret this attribute.

   These two attributes form a
   SUPABooleanClause that can operate as tuple, and together enable a single, stand-alone,
   manageable object. A SUPABooleanClauseAtomic machine to
   understand the syntax and value of the data carried by the object can NOT be
   modeled as a set
   instance of hierarchical clauses; if this functionality class.

   Note: [1..n] means that this is
   required, then a SUPABooleanClauseComposite object must be used.
   Examples of Boolean clauses multi-valued property that has
   at least one (and possibly more) attributes.

   Since this attribute could be contained represent a term in a
   SUPABooleanClauseAtomic include P, NOT P, and (P OR Q), where P
   and Q are literals SUPAPolicyClause
   (e.g., var = SUPAPolicyAction.supaPolicyActionData), a variable name complete
   SUPAPolicyClause (e.g., the supaPolicyActionData attribute
   contains text that can be either true
   or false, defines the entire action clause), or the
   name of a formula that evaluates SUPAPolicyAction to a literal). Examples invoke, each element in the string
   array is prepended with one of
   Boolean clauses the following strings:

      o 't:' (or 'term:'), to denote a term in a SUPAPolicyClause
      o 'c:' (or 'clause:'), to denote an entire SUPAPolicyClause
      o 'a:' (or 'action:'), to invoke a SUPAPolicyAction in a
             a different SUPAECAPolicyRule

   Note that are NOT in CNF are NOT(P AND Q),
   (P AND Q) OR R, and P AND (Q OR (R AND S)); their CNF equivalent
   forms are NOT P AND NOT Q, (P AND R) OR (Q AND R), and
   P AND (Q OR S) AND (Q OR S), respectively.

6.8.1.  SUPABooleanClauseAtomic Attributes

   No attributes are currently defined for the
   SUPABooleanClauseAtomic class.

6.8.2.  SUPABooleanClauseAtomic Relationships

   Currently, no relationships are defined for third case, the
   SUPABooleanClauseAtomic class. It inherits text must identify a unique
   SUPAPolicyAction (e.g., the relationships location of
   SUPAPolicyClause (see section 5.5.).

6.9. the SUPAPolicyAction,
   including its containing SUPAPolicy if applicable, MUST be
   specified).

6.13.2.2.  The Concrete Class "SUPABooleanClauseComposite" Attribute "supaPolicyActionEncoding"

   This is a mandatory concrete class that represents a
   SUPABooleanClause that can operate as a hierarchy non-zero enumerated integer attribute, and
   defines the data type of PolicyClause
   objects, where the hierarchy supaPolicyActionData attribute. This
   attribute works with another class attribute, called
   supaPolicyActionData, which contains instances the content of
   SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite
   objects. Each the action.
   These two attributes form a tuple, and together enable a machine
   to understand the syntax and value of the SUPABooleanClauseAtomic content of this
   SUPAPolicyAction object. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text
     9:  GUID
    10:  UUID
    11:  URI
    12:  FQDN
    13:  FQPN update me

   Enumerations 0 and
   SUPABooleanClauseComposite objects, including 1 signify an error state and an initialization
   state, respectively. Enumerations 2-4 are dedicated to OCL (with
   OCL 2.4 being the outermost
   SUPABooleanClauseComposite object, latest version as of this writing). QVT defines a
   set of languages [20] (the two most powerful and useful are separately manageable.

   More importantly, each SUPAECAPolicyRuleComposite object
   represents an aggregated object that defined
   by enumerations 5 and 6). Alloy is itself manageable.
   Examples of Boolean clauses that could be contained in a
   SUPABooleanClauseAtomic include ((P OR Q) AND R), language for describing
   constraints, and
   ((NOT P OR Q) AND (R OR NOT S) AND T), where P, Q, R, S, uses a SAT solver to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but is included for completeness.
   Enumerations 9-12 define a reference to the SUPAPolicyAction.

   If this class is instantiated, then this attribute SHOULD also be
   instantiated, and
   T are literals.

6.9.1.  SUPABooleanClauseComposite Attributes

   Two attributes SHOULD be part of a conformant implementation.

6.13.3.  SUPAPolicyAction Relationships

   No relationships are currently defined for this class. It inherits
   the
   SUPABooleanClauseComposite class, and are described in relationships defined by the
   following subsections.

6.9.1.1.  The Attribute "supaBoolClauseBindValue"

   This is SUPAPolicyComponentDecorator (see
   section 5.7.3.).

   Enumerations 1-4 are used to provide a mandatory non-zero integer attribute, and defines reference to an action
   object. Enumerations 5-10 are used to express the
   order in which terms bind action to
   perform as a clause. For example, the Boolean
   expression "((A AND B) OR (C AND NOT (D OR E)))" has string.

7.  Examples

   This section contains some examples that show how to use various
   objects in this draft to build policy rules.

7.1.  Example 1:  Blocking SNMP Traffic

   This example will illustrate how to use the following
   binding order: terms A and B have a bind value of 1; term C has a
   binding value of 2, and terms D SUPA information model
   to block inbound and E have a binding value of 3.

6.9.1.2. outbound SNMP traffic.

7.1.1.  Introduction

   The Attribute "supaBoolClauseIsCNF"

   This following exemplar policy was posted to the SUPA list:

      ensure that SNMP is an optional Boolean attribute. If blocked on ports at the value edgeInterface
      of the administrative domain to prevent SNMP going
      out or coming in from outside the enterprise.                (1)

   While this
   attribute is TRUE, then this SUPABooleanClauseComposite is in CNF
   form. Otherwise, simple for a human to understand, it is in DNF form.

6.9.2.  SUPABooleanClauseComposite Relationships

   Currently, the SUPABooleanClauseComposite class defined actually
   quite difficult for a single
   aggregation, which is described machine to understand in the subsections below.

6.9.2.1.  The Aggregation "SUPAHasBooleanClause" its original form.
   This is because:

      1) the text must be translated to a mandatory aggregation form that defines the set of
   SUPABooleanClause objects that are aggregated by this
   SUPABooleanClauseComposite object.

   The multiplicity device can
         understand
      2) the nature of this relationship the policy is 0..1 on not clear (due to the aggregate
   (SUPABooleanClauseComposite) side, and 1..n on inherent
         ambiguity of English)

7.1.2.  Solution Approach

   First, let's assume the part
   (SUPABooleanClause) side. This means following context:

      +-----------------------------+       +--------------+
      |      Enterprise Domain      |       | Other Domain |
      |                             |       |              |
      |    +-----+ +-----+ +-----+  |/     \|              |
      |    | NE1 | | NE2 | | NE3 +--+-------+              |
      |    +-----+ +-----+ +-----+  |\     /|              |
      +-----------------------------+       +--------------+

   In the above example, the only "edge" interface is that one or more
   SUPABooleanClauses are aggregated and used of NE3. This
   enables us to define this
   SUPABooleanClauseComposite object. The 0..1 cardinality simplify (1) to:

      block SNMP on the
   SUPABooleanClauseComposite side NE3                                             (2)

   This assumes that NE3 exists and is necessary to enable
   SUPABooleanClauses operational. This is a **big**
   assumption. This leads to exist (e.g., the observation that in a PolicyRepository) before
   they both (1) and (2),
   there are used by at least two different interpretations for each:

     1) apply a SUPABooleanClauseComposite. The semantics set of
   this aggregation is defined by actions directly to a SUPAPolicyTarget, assuming
        that the SUPAHasBooleanClauseDetail
   association class.

6.9.3. SUPAPolicyTarget understands SUPAPolicies, or
     2) apply a set of desired actions that are already translated to
        a form that a SUPAPolicyTarget can understand

   Note that a SUPAPolicyTarget could be the network device or a proxy
   for the network device.

   The Association Class "SUPAHasBooleanClauseDetail"

   This difference between these interpretations is whether a mandatory concrete association class SUPAPolicy
   applies one or more SUPAPolicyActions **directly** to a
   SUPAPolicyTarget (that is without translation to, for example, CLI
   or YANG) versus whether a SUPAPolicy, as part of its action(s),
   produces something that defines the
   semantics of device (or its proxy) can understand.

   Put another way, the SUPAHasBooleanClause aggregation. This enables first alternative shows how SUPAPolicies can
   directly control behavior, while the
   attributes and relationships second alternative shows how a
   SUPAPolicy can invoke a set of actions that the SUPAHasBooleanClauseDetail
   class to be used to constrain which SUPABooleanClause objects device (or its proxy)
   can understand. Thus, policy (1) can be aggregated by this particular SUPABooleanClauseComposite
   object instance.

6.9.3.1.  SUPAHasBooleanClauseDetail Attributes

   The SUPAHasBooleanClauseDetail class currently does not define formulated as either:

      - IF any attributes.

6.10.  The Abstract Class "SUPAECAComponent"

   This is network element has a mandatory abstract class port that defines three concrete
   subclasses, one each to represent meets the concepts criterion of reusable events,
   conditions, and actions. They are called SUPAPolicyEvent,
   SUPAPolicyCondition, and SUPAPolicyAction, respectively.

   SUPAECAComponents provide two different ways
        the role "edge interface", AND it is inside the
        EnterpriseDomain, then block SNMP traffic                   (3)
      - IF a network element is added within the EnterpriseDomain
           IF any of its ports take on the role "edge interface"
              Add a filter to construct
   SUPAPolicyClauses. block SNMP traffic for that port      (4)

   The first case is for the SUPAECAComponent to be
   used simplest, and likely what most people thought.
   Conceptually, it could look as either a SUPAPolicyVariable follows:

      Event:      SNMP traffic is sent or a SUPAPolicyValue, and received
      Condition:  IF this port implements the
   second "edgeInterface" role
                  AND IF this port is for the SUPAECAComponent to contain IN the entire clause
   text.

   For example, suppose EnterpriseDomain
      Action:     Block SNMP traffic                                (5)

   (We will define "edgeInterface" role and "EnterpriseDomain"
    later in this note.)

   A possible drawback of (5) is that it is desired to define activated by the arrival
   of a policy condition
   clause with packet event. Such events will be VERY common, meaning that
   the text 'queueDepth > 10'. Policy Engine will be doing a lot of work when most of the
   time, no policy action is needed.

   The two approaches second case could
   satisfy this be addressed as follows:

   Approach #1 (canonical form):
      SUPAPolicyCondition.supaPolicyConditionData contains the text
        'queueDepth'
      SUPAPolicyOperator.supaPolOpType

      Event:      A new port is set going to '1' (greater than)
      SUPAPolicyValue.supaPolValContent be enabled
      Condition:  IF this interface implements the "edgeInterface"
                  role AND IF this port is set to '10'

   Approach #2 (SUPAECAComponent represents IN the entire clause):
      SUPAPolicyCondition.supaPolicyConditionData contains EnterpriseDomain
      Action:     InstallFilter("SNMP traffic filter", "block")     (6)

7.1.3.  Solution for Case 1 (SUPAPolicies Control Behavior)

   This section describes the text
        'queueDepth > 10' strategy for, and outlines the steps
   taken, to build one exemplar implementation of (5).

7.1.3.1.  Strategy

   The class attribute supaECACompIsTerm, defined in subsection
   6.10.1.1, strategy is used to identify which build three clauses, one each to represent the
   event, condition, and action clauses of these two approaches is
   used our SUPAECAPolicyRule. These
   are realized by an object instance of this class.

6.10.1.  SUPAECAComponent Attributes

   A single attribute is currently defined for this class, three different **objects**, and is
   described in aggregated by the following subsection.

6.10.1.1.  The Attribute supaECACompIsTerm

   This
   SUPAECAPolicyRule (a 4th object) using three different aggregations.
   Each aggregation is an optional Boolean attribute. If the value of this
   attribute is TRUE, then this SUPAECAComponent is used as the value instance of SUPAHasPolicyClause. This yields
   a SUPAPolicyTerm structure similar to construct a SUPAPolicyClause (this is
   approach #1 that in section 6.10 above). If the value of this attribute
   is FALSE, then this SUPAECAComponent contains the text Figure 7 of the
   entire corresponding SUPAPolicyClause (this SUPA information
   model, and is approach shown below:

      C                              C
     +-------------------------+    +----------------------------+/
     | SUPABooleanClauseAtomic |    | SUPABooleanClauseComposite +----+
     +-------------+-----------+    +----------+-----------------+\   |
                   I                           I                      |
                   I                           I SUPAHasBooleanClause |
                   +---------------------------+                      |
                                               I                      |
    C                                          I                      |
   +-------------------------+           A    \ /                     |
   | SUPAECAPolicyRuleAtomic |          +------+------------+/ \      |
   +-------------+-----------+          | SUPABooleanClause + A ------+
                 I                      +--------+----------+\ /
                 I                               I
                 I                               I
         A      \ /                      A      \ /
        +--------+----------+           +--------+-----------+
        | SUPAECAPolicyRule |           |  SUPAPolicyClause  |
        +--+----+----+------+           +-------+----+----+--+
          / \  / \  / \  1..n           0..n   / \  / \  / \
           A    A    A                          |    |    |
          \ /  \ /  \ /                         |    |    |
           |    |    |                          |    |    |
           |    |    |  SUPAHasPolicyClause #1  |    |    |
           |    |    +--------------------------+    |    |
           |    |                                    |    |
           |    |         SUPAHasPolicyClause #2 in
   section 6.10 above).

6.10.2.  SUPAECAComponent Relationships

   No relationships are currently defined for this class.

6.11.  The Concrete Class "SUPAPolicyEvent"

   This is     |    |
           |    +------------------------------------+    |
           |                                              |
           |                SUPAHasPolicyClause #3        |
           +----------------------------------------------+

        Note: all 3 aggregations have a mandatory concrete class that represents the concept multiplicity of
   an Event that is applicable to 1..n - 0..n

                  Figure 29.  Creating a policy management system. Such
   an Event is defined as anything of importance to SUPAECAPolicyRule

   In Figure 29, the management
   system (e.g., a change in event, condition, and action clauses are
   represented by the system being managed and/or its
   environment) occuring on a time-axis (as defined in [19]).
   SUPAPolicyEvents can be used as part of a SUPAPolicyClause; SUPAHasPolicyClause aggregations (#1 - #3).
   The association classes for these three aggregations are not shown;
   this is done by specifying the attribute name and value of an Event in because there are no additional semantics required to
   define the supaPolicyEventData attribute meaning of the SUPAPolicyEvent. each aggregation. This
   enables event attributes also applies to be used as part of a SUPAPolicyClause.

   Note: this class does NOT model the "raw" occurrences of Events.
   Rather, it represents
   SUPAHasBooleanClause in the concept top right of an Event object whose class
   attributes describe pertinent attributes the above figure. Finally,
   recall that can trigger the
   evaluation of a SUPAECAPolicyRule.

6.11.1.  SUPAPolicyEvent Attributes

   Currently, five attributes are defined "I" arrows stand for inheritance. Hence, both the SUPAPolicyEvent
   class,
   SUPABooleanClauseAtomic and SUPABooleanClauseComposite classes
   inherit from SUPABooleanClause, which are described inherits from
   SUPAPolicyClause.

   Another important point to remember in the following subsections.

6.11.1.1.  The Attribute "supaPolicyEventIsPreProcessed"

   This Figure 29 is an optional Boolean attribute. If that classes
   inherit both attributes and relationships from their superclasses.
   For example, the value of this
   attribute is TRUE, then this SUPAPolicyEvent has been pre-
   processed by an external entity, such SUPAECAPolicyRuleAtomic, as an Event Service Bus,
   before it was received by the Policy Management System.

6.11.1.2.  The Attribute "supaPolicyEventIsSynthetic"

   This is an optional Boolean attribute. If the value of this
   attribute is TRUE, then this SUPAPolicyEvent has been produced by
   the Policy Management System. If the value of this attribute is
   FALSE, then this SUPAPolicyEvent has been produced by an entity
   in well as both the system being managed.

6.11.1.3.  The Attribute "supaPolicyEventTopic[0..n]"

   This is a mandatory array of string attributes,
   SUPABooleanClauseAtomic and contains the
   subject that this PolicyEvent describes.
   Note: [0..n] means that this is a multi-valued property that has
   zero or more attributes.

6.11.1.4.  The Attribute "supaPolicyEventEncoding"

   This is a mandatory non-zero enumerated integer attribute, and
   defines how to interpret SUPABooleanClauseComposite, all
   inherit the supaPolicyEventData class attribute.
   These two attributes form a tuple, and together enable a machine
   to understand SUPAHasPolicyClause aggregation. More specifically, the syntax
   SUPAECAPolicyRuleAtomic can aggregate SUPAPolicyClauses, and value any
   type of the data carried SUPAPolicyClause can be aggregated by the
   object instance of this class. Values include:
      0:  error
      1:  init
      2:  String
      3:  Integer
      4:  Boolean
      5:  Floating Point
      6:  DateTime

6.11.1.5.  The Attribute "supaPolicyEventData[1..n]"

   This is a mandatory attribute that defines an array any type of strings.
   Each string
   SUPAPolicyStructure (not shown in the array represents an attribute name and value
   of an Event object. The format of each string Figures; recall that this is defined as
   name:value.
   the superclass of SUPAECAPolicyRule).

   The 'name' part is decorator pattern (see Section 4.2.1.2) enables the name
   SUPAPolicyClause (or any of its concrete subclasses) to be
   optionally wrapped by one or more SUPAPolicyComponentDecorator
   objects. We will use this feature to adorn the SUPAPolicyEvent
   attribute,
   SUPABooleanPolicyClauseAtomic object with one or more
   SUPAPolicyEvent, SUPAPolicyCondition, and SUPAPolicyAction objects.

7.1.3.2.  Implementation

   Let's build up the 'value' part representation of (5) using SUPA objects. The
   SUPAECAPolicyRule is simple - it is just a SUPAECAPolicyRuleAtomic
   object (see Section 6.5). The SUPAECAPolicyRuleAtomic, as opposed to
   the value SUPAECAPolicyRuleComposite, subclass of that attribute.

   Note: [1..n] means that this SUPAECAPolicyRule is used
   because there is no need to create a multi-valued property that has
   at least one (and possibly more) attributes. For example, if
   this value hierarchy of this attribute is:

      {(startTime:0800), (endTime:1700), (date:2016-05-11),
       (timeZone:-08:00)}

   then this attribute contains four properties, called startTime,
   endTime, date, and timeZone whose values are 0800, 1700, May 11
   2016, and Pacific Standard Time, respectively.

   Note rules. This means
   that the supaPolicyEventEncoding class attribute defines how there is no need to interpret instantiate the value portion of this attribute.

   This attribute works with another SUPAECAPolicyRuleComposite
   class attribute, called
   supaPolicyEventEncoding, which defines how to interpret or its SUPAHasECAPolicyRule aggregation for this
   attribute. These example.

   There are several ways to build SUPAPolicyClauses. The following
   will show two attributes form a tuple, and together enable
   a machine different ways to understand build individual clauses. Our
   approach will be to model the syntax event and value of the data carried
   by action clauses as single
   SUPABooleanClauseAtomic objects, and then model the object instance condition clause
   as a SUPABooleanClauseComposite object. This is just to show how
   different parts of this class.

6.11.2.  SUPAPolicyEvent Relationships

   No relationships are currently defined for this class. It inherits
   the relationships defined by the SUPAPolicyComponentDecorator (see
   section 5.7.3.).

6.12. model can be used.

   The Concrete Class "SUPAPolicyCondition"

   This event clause is a mandatory concrete class that represents the concept of
   an Condition that will determine whether or not the set Boolean AND of Actions
   in the SUPAECAPolicyRule two values; we choose to which
   represent it belongs are executed or not.
   SUPAPolicyConditions can be used as part of a SUPAPolicyClause
   (e.g., var = SUPAPolicyCondition.supaPolicyConditionData) or textual string (see Section 6.10).
      => this means that SUPAECAComponent.supaECACompIsTerm is FALSE

   Both events (SNMP inbound and outbound traffic) can be represented
   by SUPAPolicyEvents (see Section 6.11) as a
   stand-alone SUPAPolicyClause (e.g., follows (we are just
   showing the supaPolicyConditionData
   attribute contains text inbound event; the outbound event is identical except
   that defines the entire condition clause).

6.12.1.  SUPAPolicyCondition Attributes

   Currently, two value of supaPolicyEventData is '{"SNMP outbound"}'):
      => supaPolicyEventData is {"SNMP inbound"}
      => supaPolicyEventEncoding is 2               // string
      => supaPolicyEventIsPreProcessed is FALSE
      => supaPolicyEventIsSynthetic is FALSE
      => supaPolicyEventTopic is {"SNMP traffic"}

   Here, we chose to instantiate all attributes are defined (mandatory and optional)
   for the SUPAPolicyCondition
   class, which sake of completeness (the first, second, and fifth attributes
   are described in all mandatory).

   The condition clause is also a Boolean AND of two values. The first
   part of the following subsections.

6.12.1.1. Boolean clause will test that a device's (sub)-interface
   belongs to a Role called edgeInterfaceRole, logically ANDed with it
   sending or receiving SNMP traffic. The Attribute "supaPolicyConditionData[1..n]"

   This following two definitions
   help clarify the first concept:

      - a Role is an abstraction that defines a mandatory array set of string attributes functionality,
        behavior, and responsibilities that contains an object can take on at
        any time during its lifecycle. Roles enable the
   content developer to
        adapt an object to different client's needs through
        transparently attached Role objects, each one representing a
        Role the object has to play in that client's context. This
        decouples the needs of this SUPAPolicyCondition object.
   Note: [1..n] means different applications from each other.
      - an "edge interface" is a Role that this is represents a multi-valued property set of device
        (sub)-interfaces that has
   at least one (and possibly more) attributes.

   This attribute works with another class attribute, called
   supaPolicyConditionEncoding, which defines how to interpret this
   attribute. These connect two attributes form a tuple, and together enable
   a machine different domains to understand the syntax and value of each
        other (e.g., router interfaces that connect the data carried
   by Enterprise
        to the object instance of Internet).

   In this class.

6.12.1.2.  The Attribute "supaPolicyConditionEncoding"

   This example, the Role is a mandatory non-zero enumerated integer attribute, and
   defines populated by information that is
   provided from the data type of received event and/or from the supaPolicyConditionData attribute.
   These two attributes form a tuple, and together enable current environment
   (e.g., a machine
   to understand topology model).

   Hence, the syntax and value first condition clause can be written as:

      (((port == 161) OR (port == 162)) AND (interfaceRole == "edge"))

   This can be modeled in a variety of ways in SUPA; the content of this simplest is
   as a SUPAPolicyCondition object. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8: (see Section 6.12), as follows:
      => SUPAECAComponent.supaECAIsTerm is FALSE
      => supaPolicyConditionData is
           {"(((port == 161) OR (port == 162)) AND
               (interfaceRole == "edge"))"}
      => supaPolicyConditionEncoding is 8           // ASCII Text

   Enumerations 1 and 2 signify an error state and an initialization
   state, respectively. Enumeraitons 3-5 are dedicated to OCL (with
   OCL 2.4 being text

   For the latest version second condition clause, we choose to again dramatically
   simplify it by mapping "EnterpriseDomain" to a particular IP subnet.
   This can also be modeled as a single string in a
   SUPAPolicyCondition, as follows:
      => SUPAECAComponent.supaECAIsTerm is FALSE
      => supaPolicyConditionData is {"IPAddress IN 204.17.5.0/27"}
      => supaPolicyConditionEncoding is 8                // ASCII text

   Each of this writing). QVT defines the SUPAPolicyCondition objects decorates a
   set separate
   instance of languages [20] (the two most powerful and useful a SUPABooleanClauseAtomic object. The three
   SUPABooleanClauseAtomic objects are defined then aggregated by enumerations 5 and 6). Alloy is a language for describing
   constraints, single
   SUPABooleanClauseComposite object (see Section 6.9). This works
   because both are concrete subclasses of SUPAPolicyClause, and uses a SAT solver thus,
   both inherit the ability to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it is informal,
   and hence, not verifiable), but have objects decorate it. This is included shown
   in Figure 30:

                 A
                +------------------------------+ 1..n
                | SUPAPolicyComponentStructure +----------------------+
                +----------------+-------------+                      |
                                / \                                   |
                                 I   SUPAHasDecoratedPolicyComponent  |
                                 I                                    |
                  +--------------+-----------+                        |
                  I                          I                        |
         A        I             A            I                        |
        +---------+--------+  +--------------+---------------+ 0..1   |
        |                  |  |                              |/ \     |
        | SUPAPolicyClause |  | SUPAPolicyComponentDecorator + A -----+
        |                  |  |                              |\ /
        +---------+--------+  +--------------+---------------+
                 / \                        / \
                  I                          I
        A         I                 A        I
      \+----------+--------+       +---------+--------+
  +----+ SUPABooleanClause |       | SUPAECAComponent |
  |   /+----------+--------+       +---------+--------+
  |              / \                        / \
  |               I                          I
  |               I                          I
  |           +---+-------+             +----+------+------------+
  |           I           I             I           I            I
  |        C  I        C  I         C   I      C    I        C   I
  |       +---+-----+ +---+----+   +----+---+ +-----+-----+ +----+---+
  |    / \| SUPA    | | SUPA   |   | SUPA   | | SUPA      | | SUPA   |
  +---- A + Boolean | | Boolean|   | Policy | | Policy    | | Policy |
       \ /| Clause  | | Clause |   | Event  | | Condition | | Action |
          |Composite| | Atomic |   +--------+ +-----------+ +--------+
          +---------+ +--------+

            Figure 30.  Pertinent Classes for completeness.

   If this class is instantiated, then this attribute SHOULD also be
   instantiated, Decoration

   The three SUPABooleanClauseAtomic objects each have their
   supaBoolClauseIsCNF attributes set to TRUE, and SHOULD be part their
   supaBoolClauseIsNegated attributes set to FALSE. The
   supaBoolClauseBindValue attributes of a conformant implementation.

6.12.2.  SUPAPolicyEvent Relationships

   No relationships are currently defined each are:

      => 1 for this class. It inherits
   the relationships defined by the SUPAPolicyComponentDecorator (see
   section 5.7.3.).

6.13. "((port == 161) OR (port == 162))"
      => 2 for "(interfaceRole == "edge")"
      => 3 for "("IPAddress IN 204.17.5.0/27")"

   The Concrete Class "SUPAPolicyAction"

   This is a mandatory concrete class that represents the concept of
   an Action, which first term is a part shown in Figure X3 below:

         C
        +--------------------------------------+
        |         SUPABooleanClauseAtomic      |
        |  C                                   |
        | +----------------------------------+ |
        | |        SUPAPolicyCondition       | |
        | |                                  | |
        | | ((port == 161) OR (port == 162)) | |
        | +----------------------------------+ |
        +--------------------------------------+

     Figure 31.  Construction of a SUPAECAPolicyRule, which may be
   executed when both Condition Clause

   Figure 31 represents the event and SUPAPolicyCondition object wrapping the condition clauses of its
   owning SUPAECAPolicyRule evaluate to true.
   SUPABooleanClauseAtomic object (see Section 4.3.5). The execution combination
   of this
   action is determined by its SUPAECAPolicyRule container, and any
   applicable SUPAPolicyMetadata objects. SUPAPolicyActions can be
   used in all three different ways:

      o as part of SUPABooleanClauseAtomic objects are then aggregated by
   a SUPAPolicyClause (e.g., var =
        SUPAPolicyAction.supaPolicyActionData)
      o single SUPABooleanClauseComposite object, as shown in Figure 32.

   The action clause uses a stand-alone SUPAPolicyClause (e.g., the SUPAPolicyAction (see Section 6.13)
   as follows:
      => supaPolicyActionData attribute contains = {"clause: deny"}
      => supaPolicyActionEncoding is 8             // ASCII text

7.1.4.  Solution for Case 2 (SUPAPolicies Do Not Control Behavior)

   This use case is different, in that defines
        the entire action clause)
      o its objective is to invoke define a SUPAECAPolicyRule
   SUPAPolicyAction that is directly readable by a SUPAPolicyTarget.
   In the third case, the execution semantics SHOULD be this example, our SUPAPolicy will invoke a NetConf operation to suspend
   the current execution of
   install a new feature (e.g., an ACL for blocking SNMP traffic) for
   **any** device whose (sub-)interface takes on the set of SUPAPolicyActions edgeInterface
   role and that are
   executing, transfer execution control is transmitting or receiving SNMP traffic.

7.1.4.1.  Approach

   Once again, we can use a SUPAECAPolicyRuleAtomic object to
   represent the invoked
   SUPAECAPolicyRule, and resume the execution of the original set
   of SUPAPolicyActions when the invoked SUPAECAPolicyRule has
   finished execution.

6.13.1.  SUPAPolicyAction Attributes

   Currently, two attributes are defined for the SUPAPolicyCondition
   class, which are described in the following subsections.

6.13.1.1.  The Attribute "supaPolicyActionData[1..n]" SUPAPolicy. This is time, we create a mandatory array of string attributes that contains the
   content new subclass of this SUPAPolicyAction object. This attribute works with
   another class attribute,
   SUPAPolicyAction, called supaPolicyActionEncoding, SUPAPolicyActionNetConf, which
   defines how to interpret this attribute. These two attributes form
   a tuple, and together enable a machine to understand the syntax
   and value is capable
   of the data carried by the object instance executing NetConf operations.

         C
        +--------------------------------+
        |   SUPABooleanClauseComposite   |
        +----+----------+----------+-----+
            / \        / \        / \
             A          A          A
            \ /        \ /        \ /
             |          |          |
             |          |          |
             |          |          +------------------+
     C      \ /         +---------+                   |
    +--------+----------------+   |                   |
    | SUPABooleanClauseAtomic |   |                   |
    |   ( port condition )    |   |                   |
    +-------------------------+   |                   |
                                  |                   |
                      C          \ /                  |
                     +------------+------------+      |
                     | SUPABooleanClauseAtomic |      |
                     |   ( interface role )    |      |
                     +-------------------------+      |
                                                      |
                                          C          \ /
                                         +------------+------------+
                                         | SUPABooleanClauseAtomic |
                                         |     ( IP address )      |
                                         +-------------------------+

          Figure 32.  Construction of this class.
   Note: [1..n] means that this the Condition Clause

7.1.4.2.  Implementation

   The SUPAPolicy is a multi-valued property that has
   at least again made up of three clauses, one (and possibly more) attributes.

   Since this attribute could each to
   represent a term in a SUPAPolicyClause
   (e.g., var = SUPAPolicyAction.supaPolicyActionData), a complete
   SUPAPolicyClause (e.g., the supaPolicyActionData attribute
   contains text that defines the entire event, condition, and action clause), or the
   name parts of our
   SUPAECAPolicyRule.

   The event clause is a SUPAECAPolicyRule to invoke, each element in simple Boolean clause; the easiest way to
   implement it is as a SUPAPolicyEvent (see Section 6.11) as follows:
      => supaPolicyEventData is {"enable port"}
      => supaPolicyEventEncoding is 2                 // string
   array
      => supaPolicyEventIsPreProcessed is FALSE
      => supaPolicyEventIsSynthetic is FALSE
      => supaPolicyEventTopic is {"new port event"}

   The condition clause is prepended with one of the following strings:

      o 't:' (or 'term:'), to denote a term same as in a SUPAPolicyClause
      o 'c:' (or 'clause:'), section 7.1.3.2.

   The action clause is more involved. We want to denote an entire SUPAPolicyClause
      o 'r:' (or 'rule:'), enable SUPA to invoke
   use NetConf operations, so the easiest thing to do is to create a SUPAECAPolicyRule

6.13.1.2.  The Attribute "supaPolicyActionEncoding"
   new subclass of SUPAPolicyAction, called SUPAPolicyActionNetConf.

   This is a mandatory non-zero enumerated integer attribute, concrete class, and
   defines has the data type following attributes (more
   could be added, of the supaPolicyActionData attribute. This course):
      => supaPolNetConfContent
      => supaPolNetConfOperation
      => supaPolNetConfURL

   The supaPolNetConfContent attribute works with another class attribute, called
   supaPolicyActionData, which contains the content of the action.
   These two attributes form a tuple, and together enable a machine
   to understand the syntax and value of the content of this
   SUPAPolicyAction object. Values include:

     0:  error
     1:  init
     2:  OCL 2.4
     3:  OCL 2.x
     4:  OCL 1.x
     5:  QVT 1.2 - Relations Language
     6:  QVT 1.2 - Operational language
     7:  Alloy
     8:  ASCII Text
     9:  GUID
    10:  UUID
    11:  URI
    12:  FQDN

   Enumerations 1 and 2 signify an error state and XML document that
   will insert (for example) an initialization
   state, respectively. Enumeraitons 3-5 are dedicated to OCL (with
   OCL 2.4 being ACL into the latest version as of this writing). QVT defines a
   set of languages [20] (the two most powerful and useful are defined
   by enumerations 5 and 6). Alloy is a language network device (or tell
   the proxy for describing
   constraints, and uses a SAT solver the device to guarantee correctness [21].
   Enumeration 8 (ASCII Text) is not recommended (since it do so).

   The supaPolNetConfOperation attribute defines the RPC operation
   that will be performed.

   The supaPolNetConfURL attribute is informal,
   and hence, not verifiable), but an XPath expression that defines
   what is included for completeness.
   Enumerations 9-12 define a reference to being manipulated (in this case, the SUPAPolicyAction.

   If desired device
   interface).

   In this class example, the SUPAPolicyNetConfOperation will have an XPath
   expression that selects the new edge interface. The RPC operation is instantiated, then this attribute SHOULD also be
   instantiated, and SHOULD be part of a conformant implementation.

6.13.2.  SUPAPolicyAction Relationships

   No relationships are currently defined
   responsible for this class. It inherits writing the relationships defined by ACL, and the SUPAPolicyComponentDecorator (see
   section 5.7.3.).

   Enumerations 1-4 are used to provide a reference to an action
   object. Enumerations 5-10 are used to express content is the action to
   perform as a string.

7.  Examples

   This will be defined in ACL, which
   drops traffic on the next version of this document. SNMP UDP ports.

8. Security Considerations

   This will be defined in the next version document defines an object-oriented information model for
   describing policy information that is independent of this document. any specific
   repository, language, or protocol. This document does not define
   any particular system implementation, including a protocol. Hence,
   it does not have any specific security requirements.

9. IANA Considerations

   This document has no actions for IANA.

10. Contributors

   The following people contributed to creating this document, and are
   listed in alphabetical order:

      Jason Coleman

11.  Acknowledgments

   This document has benefited from reviews, suggestions, comments
   and proposed text provided by the following members, listed in
   alphabetical order: Andy Bierman, Bert Wijnen, Bob Natale, Dave
   Hood, Fred Feisullin, Georgios Karagiannis, Liu (Will) Shucheng,
   Marie-Jose Montpetit.

12. References

   This section defines normative and informative references for this
   document.

12.1. Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2. Informative References

   [RFC3060]   Moore, B., Ellesson, E., Strassner, J., Westerinen,
               A., "Policy Core Information Model -- Version 1
               Specification", RFC 3060, February 2001

   [RFC3198]   Westerinen, A., Schnizlein, J., Strassner, J.,
               Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
               Carlson, M., Perry, J., Waldbusser, S., "Terminology
               for Policy-Based Management", RFC 3198, November, 2001

   [RFC3460]   Moore, B., ed., "Policy Core Information Model (PCIM)
               Extensions, RFC 3460, January 2003

   [1]         Strassner, J., "Policy-Based Network Management",
               Morgan Kaufman, ISBN 978-1558608597, Sep 2003

   [2]         Strassner, J., ed., "The DEN-ng Information Model",
               add stable URI

   [3]         Riehle, D., "Composite Design Patterns", Proceedings
               of the 1997 Conference on Object-Oriented Programming
               Systems, Languages and Applications (OOPSLA '97).
               ACM Press, 1997, Page 218-228

   [4]         DMTF, CIM Schema, v2.44,
               http://dmtf.org/standards/cim/cim_schema_v2440

   [5]         Strassner, J., ed., "ZOOM Policy Architecture and
               Information Model Snapshot", TR235, part of the
               TM Forum ZOOM project, October 26, 2014

   [6]         TM Forum, "Information Framework (SID), GB922 and
               associated Addenda, v14.5,
               https://www.tmforum.org/information-framework-sid/

   [7]         Liskov, B.H., Wing, J.M., "A Behavioral Notion of
               subtyping", ACM Transactions on Programming languages
               and Systems 16 (6): 1811 - 1841, 1994

   [8]         Klyus, M., Strassner, J., Liu, W., Karagiannis, G.,
               Bi, J., "SUPA Value Proposition",
               draft-klyus-supa-value-proposition-00, March 21, 2016

   [9]         ISO/IEC 10746-3 (also ITU-T Rec X.903), "Reference
               Model Open Distributed Processing Architecture",
               April 20, 2010

   [10]        Davy, S., Jennings, B., Strassner, J., "The Policy
               Continuum - A Formal Model", Proc. of the 2nd Intl.
               IEEE Workshop on Modeling Autonomic Communication
               Environments (MACE), Multicon Lecture Notes, No. 6,
               Multicon, Berlin, 2007, pages 65-78

   [11]        Gamma, E., Helm, R., Johnson, R., Vlissides, J.,
               "Design Patterns - Elements of Reusable Object-Oriented
               Software", Addison-Wesley, 1994, ISBN 0-201-63361-2

   [12]        Strassner, J., de Souza, J.N., Raymer, D., Samudrala,
               S., Davy, S., Barrett, K., "The Design of a Novel
               Context-Aware Policy Model to Support Machine-Based
               Learning and Reasoning", Journal of Cluster Computing,
               Vol 12, Issue 1, pages 17-43, March, 2009

   [13]        Liskov, B.H., Wing, J.M., "A Behavioral Notion of
               subtyping", ACM Transactions on Programming languages
               and Systems, 16 (6): 1811 - 1841, 1994        http://csrc.nist.gov/projects/iden_ac.html

   [14]        Martin, R.C., "Agile Software Development, Principles,
               Patterns, and Practices", Prentice-Hall, 2002,
               ISBN: 0-13-597444-5

   [15]        Halpern, J., Strassner, J., "Generic Policy Data Model
               for Simplified Use of Policy Abstractions (SUPA)"
               draft-ietf-supa-generic-policy-data-model-02,
               July 13, 2016
               draft-ietf-supa-generic-policy-data-model-03,
               April 15, 2017

   [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

   [20]        http://www.omg.org/spec/QVT/

   [21]        http://alloy.mit.edu/alloy/

   [22]        Basile, C., and Lioy, A., "Analysis of Application-
               Layer Filtering Policies with Application to HTTP",
               IEEE/ACM Transactions on Networking, Vol 23, Issue 1,
               February 2015

   [23]        van Lunteren, J., and Engbersen, T., "Fast and Scalable
               Packet Classification", IEEE Journal on Selected Areas
               in Communication, vol 21, Issue 4, September 2003

   [24]        perldoc.perl.org

   [25]        ISO/IEC/IEEE 9945, "Information technology - Portable
               Operating System Interface (POSIX) Base Specifications,
               Issue 7", September, 2009

Authors' Addresses

   John Strassner
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95138  USA
   Email: john.sc.strassner@huawei.com

   Joel Halpern
   Ericsson
   P. O. Box 6049
   Leesburg, VA 20178
   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

   This appendix describes of some of the important problems with
   previous IETF policy work., and describes the rationale for
   taking different design decisions in this document.

A.1.  PolicySetComponent vs. SUPAPolicyStructure

   The ability to define different types of policy rules is not
   present in [RFC3060] and [RFC3460], because both are based on [4],
   and this ability is not present in [4]. [RFC3060], [RFC3460], and
   [4] are all limited to CA (condition-action) policy rules. In
   addition, events are NOT defined. These limitations mean that
   RFC3060], [RFC3460], and [4] can only represent CA Policy Rules.

   In contrast, the original design goal of SUPA was to define a
   single class hierarchy that could represent different types of
   policies (e.g., imperative and declarative). Hence, it was
   decided to make SUPAPolicyStructure generic in nature, so that
   different types of policies could be defined as subclasses. This
   enables a single Policy Framework to support multiple types of
   policies.

A.2.  Flat Hierarchy vs. SUPAPolicyComponentStructure

   Figure 26 32 shows a portion of the class hierarchy of [RFC3460].

                       A
                      +--------+
                      | Policy |
                      +----+---+
                          / \
                           |
                           |
          +---------+------+------+------------+-----------+
          |         |             |            |           |
     A    |         |     A       |            |    A      |
    +-----+-----+   |    +--------+--------+   |    +------+-------+
    | PolicySet |   |    | PolicyCondition |   |    | PolicyAction |
    +-----+-----|   |    +--------+--------+   |    +------+-------+
         / \        |            / \           |          / \
          |         |             |            |           |
         ...        |            ...           |          ...
             A      |                   A      |
            +-------+--------+         +-------+-----+
            | PolicyVariable |         | PolicyValue |
            +-------+--------+         +-------+-----+
                   / \                        / \
                    |                          |
                   ...                        ...

            Figure 26. 32.  Simplified Class Hierarcy of [RFC3460]

   RFC3060], [RFC3460], and [4] defined PolicyConditions and
   PolicyActions as subclasses of Policy (along with PolicySet,
   which is the superclass of PolicyRules and PolicyGroups). This
   means that there is no commonality between PolicyConditions and
   PolicyActions, even though they are both PolicyRule components.
   From an object-oriented point-of-view, this is incorrect, since a
   PolicyRule aggregates both PolicyConditions and PolicyActions.

   In addition, note that both PolicyVariables and PolicyValues are
   siblings of PolicyRules, PolicyConditions, and PolicyActions. This
   is incorrect for several reasons:

      o a PolicyRule cannot rectly contain PolicyVariables or
        PolicyValues, so they shouldn't be at the same level of the
        class hierarchy
      o both PolicyConditions and PolicyActions can contain
        PolicyVariables and PolicyValues, which implies that both
        PolicyVariables and PolicyValues should be lower in the
        class hierarchy

   Note that in the current version of [4], PolicyVariable and
   PolicyValue are both deleted. There are other changes as well,
   but they are beyond the scope of this Appendix.

   The original design goal of SUPA was to define a single class
   hierarchy that could represent different types of policies and
   policy components. This cannot be accomplished in [RFC3460], since
   there is no notion of a policy component (or alternatively,
   PolicyCondition, PolicyAction, PolicyVariable, and PolicyValue are
   all components at the same abstraction level, which is clearly not
   correct). Hence, SUPA defined the SUPAPolicyComponentStructure
   class to capture the concept of a reusable policy component.

   In summary, SUPAPolicyStructure subclasses define the structure of
   a policy in a common way, while SUPAPolicyComponentStructure
   subclasses define the content that is contained in the structure
   of a policy, also in a common way.

A.3.  PolicyRules and PolicyGroups vs. SUPAPolicyRules

   A PolicySetComponent is an aggregation, implemented as an
   association class, that "collects instances of PolicySet
   subclasses into coherent sets of Policies". This is a recursive
   aggregation, with multiplicity 0..n - 0..n, on the PolicySet
   class.

   Since this is a recursive aggregation, it means that a PolicySet
   can aggregate zero or more PolicySets. This is under-specified,
   and can be interpreted in one of two ways:

      1. A PolicySet subclass can aggregate any PolicySet subclass
         (PolicyRules can aggregate PolicyRules and PolicyGroups, and
         vice-versa)
      2. PolicyRules can aggregate PolicyRules, and PolicyGroups can
         aggregate PolicyGroups, but neither class can aggregate the
         other type of class

   Both interpretations are ill-suited for policy-based management.
   The problem with the first is that if PolicyGroup is the mechanism
   for grouping, why can a PolicyRule aggregate a PolicyGroup? This
   implies that PolicyGroups are not needed. The problem with the
   second is that PolicyGroups cannot aggregate PolicyRules (which
   again implies that PolicyGroups are not needed).

   Furthermore, there are no mechanisms defined in the [RFC3460]
   model to prevent loops of PolicyRules. This is a problem, because
   EVERY PolicyRule and PolicyGroup inherits this recursive
   aggregation.

   This is why this document uses the composite pattern. First, this
   pattern clearly shows what object is aggregating what other
   object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate a
   SUPAECAPolicyRuleComposite). Second, it does not allow a
   SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule
   (this is discussed more in the following subsection).

A.3.1.  Sub-rules

   Sub-rules (also called nested policy rules) enable a policy rule to
   be contained within another policy rule. These have very complex
   semantics, are very hard to debug, and provide limited value. They
   also require a complex set of aggregations (see section A.4.).

   The main reason for defining sub-rules in [RFC3460] is to enable
   "complex policy rules to be constructed from multiple simpler
   policy rules". However, the composite pattern does this much more
   efficiently than a simple recursive aggregation, and avoids the
   ambiguous semantics of a recursive aggregation. This latter point
   is important, because if PolicyRule and/or PolicyGroup is
   subclassed, then all subclasses still inherit this recursive
   aggregation, along with its ambiguous semantics.

A.4.  PolicyConditions and PolicyActions vs. SUPAECAComponent

   There is no need to use the SimplePolicyCondition and
   ComplexPolicyCondition objects defined in [RFC3460], since the
   SUPAPolicyComponentStructure uses the decorator pattern (see
   section 5.7) to provide more extensible types of conditions than is
   possible with those classes. This also applies for the
   SimplePolicyAction and the ComplexPolicyAction classes defined in
   [RFC3460].

   More importantly, this removes the need for a complex set of
   aggregations (i.e., PolicyComponent, PolicySetComponent,
   PolicyConditionStructure, PolicyConditionInPolicyRule,
   PolicyConditionInPolicyCondition, PolicyActionStructure,
   PolicyActionInPolicyRule, and PolicyActionInPolicyAction).
   Instead, ANY SUPAECAComponent is defined as a decorator (i.e., a
   subclass of SUPAPolicyComponentDecorator), and hence, Any
   SUPAECAComponent is wrapped onto a concrete subclass of
   SUPAPolicyClause using the SAME aggregation
   (SUPAHasDecoratedPolicyComponent). This is a significantly simpler
   design that is also more powerful.

A.5.  The SUPAPolicyComponentDecorator Abstraction

   One of the problems in building a policy model is the tendency to
   have a multitude of classes, and hence object instances, to
   represent different combinations of policy events, conditions, and
   actions. This can lead to class and/or relationship explosion, as
   is the case in [RFC3460], [4], and [6].

   For example, [RFC3460] defines five subclasses of PolicyCondition:
   PolicyTimePeriodCondition, VendorPolicyCondition,
   SimplePolicyCondition, CompoundPolicyCondition, and
   CompoundFilterCondition. Of these:

      o PolicyTimePeriodCondition is a data structure, not a class
      o VendorPolicyCondition represents a condition using two
        attributes that represent a multi-valued octet string
      o SimplePolicyCondition, CompoundPolicyCondition, and
        CompoundFilterCondition all have ambiguous semantics

   SimplePolicyCondition represents an ordered 3-tuple, in the form
   {variable, match, value}. However, the match operator is not
   formally modeled. Specifically, "the 'match' relationship is to
   be interpreted by analyzing the variable and value instances
   associated with the simple condition". This becomes problematic
   for several cases, such as shallow vs. deep object comparisons.
   More importantly, this requires two separate aggregations
   (PolicyVariableInSimplePolicyCondition and
   PolicyValueInSimplePolicyCondition) to associate variables and
   values to the SimplePolicyCondition, respectively. Since [RFC3460]
   defines all relationships as classes, this means that the
   expression "Foo > Bar" requires a total of FIVE objects (one each
   for the variable and value, one for the SimplePolicyCondition, and
   one each to associate the variable and value with the
   SimplePolicyCondition).

   This is exacerbated when SimplePolicyConditions are used to build
   CompoundPolicyConditions. In addition to the above complexity
   (which is required for each SimplePolicyCondition), a new
   aggregation (PolicyConditionInPolicyCondition) is required to
   aggregation PolicyConditions. Thus, the compound expression:
   "((Foo > Bar) AND (Foo < Baz))" requires a total of THIRTEEN
   objects (five for each of the terms being ANDed, plus one for the
   CompoundPolicyCondition, and two to aggregate each term to the
   CompoundPolicyCondition).

   Note that in the above examples, the superclasses of each of the
   relationships are omitted for clarity. In addition, [RFC3460] is
   built using inheritance; this means that if a new function is
   required, a new class must be built (e.g., CompoundFilterCondition
   is a subclass, but all it adds is one attribute).

   In constrast, the Decorator Pattern enables behavior to be
   selectively added to an individual object, either statically or
   dynamically, without having to build association classes. In
   addition, the decorator pattern uses composition, instead of
   inheritance, to avoid class explosion. This means that a new
   variable, value, or even condition class can be defined at
   runtime, and then all or part of that class can dynamically wrap
   an existing object without need for recompilation and
   redeployment.

A.6.  The Abstract Class "SUPAPolicyClause"

   This abstraction is missing in [RFC3060], [RFC3460], [4], and [6].
   SUPAPolicyClause was abstracted from DEN-ng [2], and a version of
   this class is in the process of being added to [5]. However, the
   class and relationship design in [5] differs significantly from
   the corresponding designs in this document.

   SUPAPolicyClause further reinforces the different between a policy
   rule and a component of a policy rule by abstracting the content
   of a policy rule as a reusable object. This is fundamental for
   enabling different types of policy rules (e.g., imperative and
   declarative) to to be represented using the same constructs.

A.7.  Problems with the RFC3460 Version of PolicyVariable

   The following subsections define a brief, and incomplete, set of
   problems with the implementation of [RFC3460] (note that [RFC3060
   did not define variables, operators, and/or values).

A.7.1.  Object Bloat

   [RFC3460] used two different and complex mechanisms for providing
   generic get and set expressions. PolicyVariables were subclassed
   into two subclasses, even though they performed the same semantic
   function. This causes additional problems:

      o PolicyExplicitVariables are for CIM compatibility; note that
        the CIM does not contain either PolicyVariables or
        PolicyValues ([4])
      o PolicyImplicitVariable subclasses do not define attributes;
        rather, they are bound to an appropriate subclass of
        PolicyValue using an association

   Hence, defining a variable is relatively expensive in [RFC3460],
   as in general, two objects and an association must be used. The
   objects themselves do not define content; rather, their names are
   used as a mechanism to identify an object to match. This means
   that an entire object must be used (instead of, for example, an
   attribute), which is wasteful. It also make it difficult to
   adjust constraints at runtime, since the constraint is defined in
   a class that is statically defined (and hence, requires
   recompilation and possibly redeployment if it is changed).

A.7.2.  Object Explosion

   The above three problems lead to class explosion (recall that in
   [RFC3060], [RFC3460], and [4], associations are implemented as
   classes).

   In contrast to this approach, the approach in this document keeps
    the idea of the class hierarchy for backwards compatibility, but
   streamlines the implementation. Specifically:

      1. The decorator pattern is an established and very used
         software pattern (it dates back to at least 1994 [11]).
      2. The use of a single association class
         (i.e., SUPAHasDecoratedPolicyComponentDetail) can represent
         more constraints than is possible in the approaches of
         [RFC3460] and [4] in a much more flexible manner, due to its
         function as a decorator of other objects.
      3. Note that there is no way to enforce the constraint matching
         in [RFC3460] and [6]; the burden is on the developer to
         check and see if the constraints specified in one class are
         honored in the other class.
      4. If these constraints are not honored, there is no mechanism
         specified to define the clause as incorrectly formed.

A.7.3.  Specification Ambiguities

   There are a number of ambiguities in [RFC3460].

   First, [RFC3460] says: "Variables are used for building individual
   conditions". While this is true, variables can also be used for
   building individual actions. This is reflected in the definition
   for SUPAPolicyVariable.

   Second, [RFC3460] says: "The variable specifies the property of a
   flow or an event that should be matched when evaluating the
   condition." While this is true, variables can be used to test many
   other things than "just" a flow or an event. This is reflected in
   the SUPAPolicyVariable definition.

   Third, the [RFC3460] definition requires the use of associations
   in order to properly constrain the variable (e.g., define its
   data type, the range of its allowed values, etc.). This is both
   costly and inefficient.

   Fourth, [RFC3460] is tightly bound to the DMTF CIM schema [4].
   The CIM is a data model (despite its name), because:

      o It uses keys and weak relationships, which are both concepts
        from relational algebra and thus, not technology-independent
      o It has its own proprietary modeling language
      o It contains a number of concepts that are not defined in UML
        (including overriding keys for subclasses)

   Fifth, the class hierarchy has two needless classes, called
   SUPAImplicitVariable and SUPAExplicitVariable. These classes do
   not define any attributes or relationships, and hence, do not
   add any semantics to the model.

   Finally, in [RFC3460], defining constraints for a variable is
   limited to associating the variable with a PolicyValue. This is
   both cumbersome (because associations are costly; for example,
   they equate to a join in a relational database management system),
   and not scalable, because it is prone to proliferating PolicyValue
   classes for every constraint (or range of constraints) that is
   possible. Therefore, in SUPA, this mechanism is replaced with
   using an association to an association class that defines
   constraints in a much more general and powerful manner (i.e.,
   the SUPAHasDecoratedPolicyComponentDetail class).

A.8.  Problems with the RFC3460 Version of PolicyValue

   The following subsections define a brief, and incomplete, set of
   problems with the implementation of [RFC3460] (note that [RFC3060
   did not define variables, operators, and/or values).

A.8.1.  Object Bloat

   [RFC3460] defined a set of 7 subclasses; three were specific to
   networking (i.e., IPv4 Address, IPv6 Address, MAC Address) and 4
   (PolicyStringValue, PolicyBitStringValue, PolicyIntegerValue, and
   PolicyBooleanValue) were generic in nature. However, each of these
   objects defined a single class attribute. This has the same two
   problems as with PolicyVariables (see section 5.9.1.1):

     1. Using an entire object to define a single attribute is very
        wasteful and expensive
     2. It also make it difficult to adjust constraints at runtime,
        since the constraint is defined in a class that is statically
        defined (and hence, requires recompilation and possibly
        redeployment if it is changed).

A.8.2.  Object Explosion

   [RFC3460] definition requires the use of associations
   in order to properly constrain the variable (e.g., define its
   data type, the range of its allowed values, etc.). This is both
   costly and inefficient (recall that in [RFC3060], [RFC3460], and
   [4], associations are implemented as classes).

A.8.3.  Lack of Constraints

   There is no generic facility for defining constraints for a
   PolicyValue. Therefore, there is no facility for being able to
   change such constraints dynamically at runtime.

A.8.4.  Tightly Bound to the CIM Schema

   [RFC3460] is tightly bound to the DMTF CIM schema [4]. The CIM is
   a data model (despite its name), because:

      o It uses keys and weak relationships, which are both concepts
        from relational algebra and thus, not technology-independent
      o It has its own proprietary modeling language
      o It contains a number of concepts that are not defined in UML
        (including overriding keys for subclasses)

A.8.5.  Specification Ambiguity

   [RFC3460] says: It is used for defining values and constants used
   in policy conditions". While this is true, variables can also be
   used for building individual actions. This is reflected in the
   SUPAPolicyVariable definition.

A.8.6.  Lack of Symmetry

   Most good information models show symmetry between like components.
   [RFC3460] has no symmetry in how it defines variables and values.
   In contrast, this document recognizes that variables and values
   are just terms in a clause; hence, the only difference in the
   definition of the SUPAPolicyVariable and SUPAPolicyValue classes
   is that the content attribute in the former is a single string,
   whereas the content attribute in the latter is a string array.
   In particular, the semantics of both variables and values are
   defined using the decorator pattern, along with the attributes of
   the SUPAPolicyComponentDecorator and the
   SUPAHasDecoratedPolicyComponentDetail classes.