[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-supa-generic-policy-info-model

Network Working Group                                     J. Strassner
Internet Draft                                     Huawei Technologies
Intended status: Standard Track
Expires: January 4, 2016                                  July 4, 2015


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


Abstract

   Simplified Use of Policy Abstractions (SUPA) defines an interface
   to a network management function that takes high-level, possibly
   network-wide policies as input and creates element configuration
   snippets as output. SUPA addresses the needs of operators and
   application developers to represent multiple types of policy
   rules, which vary in the level of abstraction, to suit the needs
   of different actors. This document defines a single common
   extensible framework for representing different types of policy
   rules, in the form of a set of information model fragments, that
   is independent of language, protocol, repository, and the level
   of abstraction of the content of the policy rule. This enables a
   common set of concepts defined in this set of information models
   to be mapped into 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.

   Specifically, this document defines three information models:

      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 paradigm; this is called the SUPA
          Eca Policy Rule Information Model (EPRIM)
      3.  A framework for defining a policy model that uses a
          declarative (e.g., intent-based) paradigm; this is called
          the SUPA Logic Statement Information Model (LSIM)

   The combination of the GPIM and the EPRIM, or the GPIM and the
   LSIM, provide an extensible framework for defining policy that
   uses an event-condition-action or declarative representation that
   is independent of data repository, data definition language, query
   language, implementation language, and protocol. A specific design
   goal of SUPA is to enable ECA policy rules and declarative policy
   statements to be used together or separately. This is achieved by
   deriving both the EPRIM and the LSIM from the GPIM.




Strassner                 Expires January 4, 2016             [Page 1]


Internet-Draft            SUPA Generic Policy Model          July 2015


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 26, 2015.


Copyright Notice

   Copyright (c) 2014 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

   1. Introduction ................................................. 8
   2. Conventions Used in This Document ............................ 8
   3. Terminology .................................................. 8
      3.1. Acronyms................................................. 8
      3.2. Definitions ............................................. 9




Strassner                 Expires January 4, 2016             [Page 2]


Internet-Draft            SUPA Generic Policy Model          July 2015

Table of Contents (continued)

         3.2.1. Core Terminology ................................... 9
            3.2.1.1. Information Model ............................. 9
            3.2.1.2. Data Model ................................... 10
            3.2.1.3. Container .................................... 10
            3.2.1.4. PolicyContainer .............................. 10
         3.2.2. Policy Terminology ................................ 10
            3.2.2.1. SUPAPolicy ................................... 11
            3.2.2.2. SUPAPolicyStatement .......................... 11
            3.2.2.3. SUPAECAPolicyRule ............................ 11
            3.2.2.4. SUPALogicStatement ........................... 11
            3.2.2.5. SUPAMetadata ................................. 12
            3.2.2.6. SUPAPolicyTarget ............................. 12
            3.2.2.7. SUPAPolicySubject ............................ 12
         3.2.3. Modeling Terminology .............................. 13
            3.2.3.1. Inheritance .................................. 13
            3.2.3.2. Relationship ................................. 13
            3.2.3.3. Association .................................. 13
            3.2.3.4. Aggregation .................................. 13
            3.2.3.5. Composition .................................. 14
            3.2.3.6. Association Class ............................ 14
            3.2.3.7. Multiplicity ................................. 14
            3.2.3.8. Navigability ................................. 14
            3.2.3.9. Abstract Class ............................... 15
            3.2.3.10. Concrete Class .............................. 15
         3.2.4.  Mathematical Logic Terminology ................... 15
            3.2.4.1. Predicate .................................... 15
            3.2.4.2. Logic Operators .............................. 15
               3.2.4.2.1. Propositional Logic Connectives ......... 15
               3.2.4.2.2. First Order Logic Quantifiers ........... 16
            3.2.4.3. Propositional Logic .......................... 16
            3.2.4.4. First-Order Logic ............................ 16
      3.3. Symbology .............................................. 17
         3.3.1. Inheritance ....................................... 17
         3.3.2. Association ....................................... 17
         3.3.3. Aggregation ....................................... 17
         3.3.4. Composition ....................................... 18
         3.3.5. Association Class ................................. 18
         3.3.6. Logical Connectives ............................... 18
         3.3.7. Quantifiers ....................................... 18
   4. Policy Abstraction Architecture ............................. 19
      4.1. Motivation ............................................. 20
      4.2. SUPA Approach .......................................... 21
      4.3. SUPA Generic Policy Information Model Overview ......... 21
      4.4. Structure of SUPA Policies ............................. 24
         4.4.1. ECA Policy Rule Structure ......................... 24
         4.4.2. Logical Statement Structure ....................... 25
      4.5. GPIM Assumptions ....................................... 27
      4.6. Scope of Previous Work ................................. 28


Strassner                 Expires January 4, 2016             [Page 3]


Internet-Draft            SUPA Generic Policy Model          July 2015

Table of Contents (continued)

   5. GPIM Model .................................................. 29
      5.1. Overview ............................................... 29
      5.2. The Abstract Class "SUPAPolicy" ........................ 29
         5.2.1. SUPAPolicy Attributes ............................. 32
            5.2.1.1. The Attribute "supaObjectIDContent" .......... 32
            5.2.1.2. The Attribute "supaObjectIDFormat" ........... 32
            5.2.1.3. The Attribute "supaPolicyDescription" ........ 32
            5.2.1.4. The Attribute "supaPolicyName" ............... 32
         5.2.2. SUPAPolicy Relationships .......................... 33
            5.2.2.1. The Relationship "SUPAPolicyMetadata" ........ 33
            5.2.2.2. The Association Class
                     "SUPAPolicyMetadataDetail" ................... 33
      5.3. The Abstract Class "SUPAPolicyAtomic" .................. 33
         5.3.1. SUPAPolicyAtomic Attributes ....................... 34
            5.3.1.1. The Attribute "supaPolicyDeployStatus" ....... 34
            5.3.1.2. The Attribute "supaPolicyExecStatus" ......... 34
         5.3.2. SUPAPolicyAtomic Relationships .................... 34
            5.3.2.1. The Aggregation "SUPAPAHasPolicyStmts" ....... 34
            5.3.2.2. The Association Class
                     "SUPAPAHasPolicyStmtDetail" .................. 35
      5.4. The Concrete Class "SUPAPolicyComposite" ............... 35
         5.4.1. SUPAPolicyComposite Attributes .................... 35
            5.4.1.1. The Attribute "supaPCFailureStrategy" ........ 36
            5.4.1.2. The Attribute "supaPCIsMatchAll" ............. 36
         5.4.2. SUPAPolicyComposite Relationships ................. 36
            5.4.2.1. The Aggregation "HasSUPAPolicies" ............ 36
            5.4.2.2. The Association Class "HasSUPAPolicyDetail" .. 37
      5.5. The Abstract Class "SUPAPolicyStatement" ............... 37
         5.5.1. SUPAPolicyStatement Attributes .................... 39
            5.5.1.1. The Attribute "supaPolStmtAdminStatus" ....... 39
            5.5.1.2. The Attribute "supaPolStmtExecStatus" ........ 40
            5.5.1.3. The Attribute "supaPolStmtIsCNF" ............. 40
         5.5.2. SUPAPolicyStatement Subclasses .................... 40
            5.5.2.1. The Concrete Class "SUPAEncodedClause" ....... 41
               5.5.2.1.1. SUPAEncodedClause Attributes ............ 42
                  5.5.2.1.1.1. The Attribute "supaClauseContent" .. 42
                  5.5.2.1.1.2. The Attribute "supaClauseFormat" ... 42
                  5.5.2.1.1.3. The Attribute "supaClauseResponse" . 42
         5.5.3. SUPAPolicyStatement Relationships ................. 43
            5.5.3.1. The Aggregation "SUPAPolicyTermsInStmt" ...... 43
            5.5.3.2. The Association Class
                     "SUPAPolicyTermsInStmtDetail" ................ 43
               5.5.3.2.1. SUPAPolicyStmtDetail Attributes ......... 43
      5.6. The Abstract Class "SUPAPolicySubject" ................. 43
         5.6.1. SUPAPolicySubject Attributes ...................... 45
            5.6.1.1. The Attribute
                     "supaPolicySubjectIsAuthenticated" ........... 45



Strassner                 Expires January 4, 2016             [Page 4]


Internet-Draft            SUPA Generic Policy Model          July 2015

Table of Contents (continued)

         5.6.2. SUPAPolicySubject Relationships ................... 45
            5.6.2.1. The Relationship "SUPAPolicySubjects" ........ 45
            5.6.2.2. The Association Class
                      "SUPAPolicySubjectDetail" ................... 46
               5.6.2.2.1. SupaPolicySubjectDetail Attributes ...... 46
                  5.6.2.2.1.1. The Attribute
                          "supaPolicySubjectIsVerified" ........... 46
      5.7. The Abstract Class "SUPAPolicyTarget" .................. 46
         5.7.1. SUPAPolicyTarget Attributes ....................... 47
         5.7.2. SUPAPolicyTarget Relationships .................... 47
            5.7.2.1. The Relationship "SUPAPolicyTargets" ......... 47
            5.7.2.2. The Association Class "SUPAPolicyTargetDetail" 47
               5.7.2.2.1. SupaPolicyTargetDetail Attributes ....... 47
                  5.7.2.2.1.1. The Attribute
                               "supaPolicyTargetEnabled" .......... 47
      5.8. The Abstract Class "SUPAPolicyTerm" .................... 48
         5.8.1. SUPAPolicyTerm Attributes ......................... 49
            5.8.1.1 The Attribute "supaTermIsNegated" ............. 49
         5.8.2. SUPAPolicyTerm Relationships ...................... 49
            5.8.2.1. The Aggregation "SUPAPolicyTermsInStmt" ...... 49
            5.8.2.2. The Association Class
                     "SUPAPolicyTermsInStmtDetail" ................ 49
            5.8.2.2.1. SUPAPolicyTermsInStmtDetail Attributes ..... 50
               5.8.2.2.1.1. The Attribute
                            "supaPolTermOCLConstraint" ............ 50
         5.8.3. SUPAPolicyTerm Subclasses ......................... 50
            5.8.3.1. The Concrete Class "SUPAPolicyVariable" ...... 51
               5.8.3.1.1. Problems with the RFC3460 Version of
                          PolicyVariable .......................... 51
               5.8.3.1.2. SUPAPolicyVariable Attributes ........... 52
                  5.8.3.1.2.1. The Attribute
                               "supaAllowedValueTypes[0..n]" ...... 52
                  5.8.3.1.2.2. The Attribute "supaPolVarContent" .. 52
                  5.8.3.1.2.3. The Attribute "supaPolVarType" ..... 52
               5.8.3.1.3. SUPAPolicyVariable Subclasses ........... 53
            5.8.3.2. The Concrete Class "SUPAPolicyOperator" ...... 53
               5.8.3.2.1. Problems with the RFC3460 Version ....... 53
               5.8.3.2.2. SUPAPolicyOperator Attributes ........... 53
                  5.8.3.2.2.1. The Attribute "supaPolOpType" ...... 54
            5.8.3.3. The Concrete Class "SUPAPolicyValue" ......... 54
               5.8.3.3.1. Problems with the RFC3460 Version of
                          PolicyValue ............................. 55
               5.8.3.3.2. SUPAPolicyValue Attributes .............. 55
                  5.8.3.3.2.1. The Attribute "supaPolValContent" .. 56
                  5.8.3.3.2.2. The Attribute "supaPolValType" ..... 56
               5.8.3.3.3. SUPAPolicyValue Subclasses .............. 56
      5.9. The Abstract Class "SUPAPolicyMetadata" ................ 56
         5.9.1. SUPAPolicyMetadata Attributes ..................... 56
         5.9.2. SUPAPolicyMetadata Relationships .................. 56

Strassner                 Expires January 4, 2016             [Page 5]


Internet-Draft            SUPA Generic Policy Model          July 2015

Table of Contents (continued)

   6. SUPA ECAPolicyRule Information Model ........................ 57
      6.1. Overview ............................................... 57
      6.2. Constructing a SUPAECAPolicyRule ....................... 58
      6.3. Working With SUPAECAPolicyRules ........................ 59
      6.4. The Concrete Class "SUPAECAPolicyRule" ................. 60
         6.4.1. SUPAECAPolicyRule Attributes ...................... 62
            6.4.1.1. The Attribute "supaECAPolicyIsMandatory" ..... 62
            6.4.1.2. The Attribute "supaECAPolicyPriority" ........ 62
         6.4.2. SUPAECAPolicyRule Relationships ................... 63
            6.4.2.1. The Aggregation "SUPAECAPolicyRules" ......... 63
               6.4.2.1.1. The Association Class
                          "HasSUPAECAComponentDetail" ............. 63
         6.4.3. SUPAECAPolicyRule Subclasses ...................... 63
            6.4.3.1. The Concrete Class "SUPAECAPolicyRuleAtomic" . 64
               6.4.3.1.1. SUPAECAPolicyRuleAtomic Attributes ...... 64
               6.4.3.1.2. SUPAECAPolicyRuleAtomic Relationships ... 64
            6.4.3.2. The Concrete Class
                     "SUPAECAPolicyRuleComposite" ................. 65
               6.4.3.2.1. SUPAECAPolicyRuleAtomic Attributes ...... 65
                  6.4.3.2.1.1. The Attribute "supaECAEvalStrategy"  65
                  6.4.3.2.1.2. The Attribute "supaECAFailStrategy"  65
               6.4.3.2.2. SUPAECAPolicyRuleComposite Relationships  66
                  6.4.3.2.2.1 The Aggregation "SUPAECAPolicyRules"  66
                  6.4.3.2.2.2. The Association Class
                               "SUPAECAPolicyRuleDetail" .......... 66
      6.5. SUPAPolicyStatement Subclasses ......................... 66
         6.5.1. Designing SUPAPolicyStatements Using
                 SUPABooleanClauses ............................... 66
         6.5.2. The Abstract Class"SUPABooleanClause" ............. 67
            6.5.2.1. SUPABooleanClause Attributes ................. 68
               6.5.2.1.1. The Attribute "supaBoolIsNegated" ....... 69
               6.5.2.1.2. The Attribute "supaPolStmtBindValue" .... 69
            6.5.2.2. SUPABooleanClause Relationships .............. 69
               6.5.2.2.1. The Relationship "SUPABooleanClauses" ... 69
                  6.5.2.2.1.1. The Association Class
                               "SUPABooleanClauseDetail" .......... 69
         6.5.3. SUPABooleanClause Subclasses ...................... 70
            6.5.3.1. The Abstract Class "SUPABooleanClauseAtomic" . 70
            6.5.3.2. The Abstract Class
                     "SUPABooleanClauseComposite" ................. 70
               6.5.3.2.1. SUPABooleanClauseComposite Attributes ... 70
                  6.5.3.2.1.1. The Attribute "supaBoolClauseIsCNF"  71
         6.6. The Abstract Class "SUPAECAComponent" ............... 71
            6.6.1. SUPAECAComponent Attributes .................... 71
            6.6.2. SUPAECAComponent Relationships ................. 71
               6.6.2.1. The Aggregation "SUPAECAComponentsInTerms"  71
                  6.6.2.1.1. The Association Class
                             "SUPAECAComponentsInTermDetail" ...... 72


Strassner                 Expires January 4, 2016             [Page 6]


Internet-Draft            SUPA Generic Policy Model          July 2015

Table of Contents (continued)


         6.6.3. SUPAECAComponent Subclasses ....................... 72
            6.6.3.1. The Concrete Class"SUPAEvent" ................ 72
            6.6.3.2. The Concrete Class"SUPACondition" ............ 72
            6.6.3.3. The Concrete Class"SUPAAction" ............... 72
   7. SUPA Logic Statement Information Model ...................... 73
      7.1. Overview ............................................... 73
      7.2. Constructing a SUPAPLStatement ......................... 73
      7.3. Working With SUPAPLStatements .......................... 73
      7.4. The Abstract Class "SUPALogicClause" ................... 73
      7.5. The Abstract Class "SUPAPLStatement" ................... 74
         7.5.1. SUPAPLStatement Attributes ........................ 74
         7.5.2. SUPAPLStatement Relationships ..................... 74
         7.5.3. SUPAPLStatement Subclasses ........................ 75
         7.5.3.1. The Concrete Class "SUPAPLArgument" ............. 75
         7.5.3.2. The Concrete Class "SUPAPLPremise" .............. 75
         7.5.3.3. The Concrete Class "SUPAPLConclusion" ........... 75
      7.6. Constructing a SUPAFOLStatement ........................ 75
      7.7. Working With SUPAFOLStatements ......................... 75
         7.7.1. SUPAFOLStatement Attributes ....................... 75
         7.7.2. SUPAFOLStatement Relationships .................... 75
         7.7.3. SUPAFOLStatement Subclasses ....................... 75
         7.7.3.1. The Concrete Class "SUPAGoalHead" ............... 75
         7.7.3.2. The Concrete Class "SUPAGoalBody" ............... 75
      7.8. Combining Different Types of SUPAFOLStatements ......... 75
   8. Examples .................................................... 76
      8.1. SUPAECAPolicyRule Examples ............................. 76
      8.2. SUPALogicStatement Examples ............................ 76
      8.3. Mixing SUPAECAPolicyRules and SUPALogicStatements ...... 76
   9. Security Considerations  .................................... 76
   10. IANA Considerations ........................................ 76
   11. Acknowledgments ............................................ 76
   12. References ................................................. 76
      12.1. Normative References .................................. 76
      12.2. Informative References  ............................... 76
   Authors' Addresses ............................................. 7














Strassner                 Expires January 4, 2016             [Page 7]


Internet-Draft            SUPA Generic Policy Model          July 2015


1. Introduction

   The Simplified Use Policy Abstractions (SUPA) addresses the needs
   of operators and application developers to represent multiple types
   of policy rules using a common structure. This enables policy rules
   to be defined independent of language, protocol, repository, and
   the level of abstraction of the content of the policy rule. This
   common framework currently takes the form of a set of three
   information model fragments. The SUPA Generic Policy Information
   Model (GPIM) defines a common set of policy management concepts
   that are independent of the type of policy rule, while the SUPA
   ECA Policy Rule Information Model (EPRIM) and SUPA Logic Statement
   Information Model (LSIM) define information models that are
   specific to the needs of Event-Condition-Action (ECA) policy rules
   and statements that are subsets of either Propositional Logic (PL)
   or First-Order Logic (FOL), respectively.



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
   CNF        Conjunctive Normal Form
   DNF        Disjunctive Normal Form
   ECA        Event-Condition-Action
   EPRIM      (SUPA) ECA Policy Rule Information Model
   FOL        First Order Logic
   GPIM       (SUPA) Generic Policy Information Model
   LSIM       (SUPA) Logic Statement Information Model
   NETCONF    Network Configuration protocol
   OAM&P      Operations, Administration, Management, and Provisioning
   OID        Object IDentifier



Strassner                 Expires January 4, 2016             [Page 8]


Internet-Draft            SUPA Generic Policy Model          July 2015


   PAP        Policy Administration Point
   PDP        Policy Decision Point
   PEP        Policy Enforcement Point
   PIP        Policy Information Point
   PL         Propositional Logic
   PR         Policy Repository
   PXP        Policy Execution Point
   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".

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 different than that of [RFC3198]. An
   information model is defined in [RFC3198] as: "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." The SUPA definition is
   more specific, and corrects the following ambiguities:

      o Most information models do not define operations; this is
        typically implementation-specific and a function of (at least)
        the language, protocol, and data repository used.
      o It is unclear what the difference is between the terms
        "properties" and "attributes" (these are typically synonyms in
        modeling terminology)
      o It is unclear what is meant by "software usage".
      o It is unclear what is meant by "platform".



Strassner                 Expires January 4, 2016             [Page 9]


Internet-Draft            SUPA Generic Policy Model          July 2015


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
   protocol (typically, but not necessarily, all three).

   Note: this definition is different than that of [RFC3198]. A data
   model is defined in [RFC3198] as: "A mapping of the contents of an
   information model into a form that is specific to a particular type
   of data store or repository." The SUPA definition is more specific.
   For example, it takes into account differences between two
   implementations that use the same protocol, implementation
   language, and data repository, but which have different data
   definition and/or query protocols.

3.2.1.3. 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.4. 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 OAMP 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.


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 the GPIM to ensure name uniqueness. Similarly, the prefix
   "supa" is defined for all SUPA class attributes.






Strassner                 Expires January 4, 2016            [Page 10]


Internet-Draft            SUPA Generic Policy Model          July 2015


3.2.2.1. SUPAPolicy

   A SUPAPolicy is an abstract class that is a type of
   PolicyContainer.

   SUPAPolicy is defined generically 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 at least create,
   read, query, update, and delete functions are supported.


3.2.2.2. SUPAPolicyStatement

   A SUPAPolicyStatement is an abstract class that contains an
   individual or group of related functions that are used to build
   different types of policies. This document defines two different
   types of policies: ECA policy rules and declarative policies.
   These different types of policies can be used to define a set of
   actions to take, or declaratively define a goal to be achieved
   and/or a set of facts to be used.

3.2.2.3. SUPAECAPolicyRule

   An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an
   abstract class that represents a policy rule as a three-tuple,
   consisting of an event, a condition, and an action clasue. Each
   clause MUST be defined by at least one SUPAPolicyStatement.
   Optionally, the SUPAECAPolicyRule MAY contain one or more
   SUPAPolicySubjects, one or more SUPAPolicyTargets, and one or
   more SUPAPolicyMetadata objects.

3.2.2.4. SUPALogicStatement

   A SUPALogicStatement is an abstract class that represents
   declarative (also called intent-based) policies. A
   SUPALogicStatement MUST contain at least one SUPAPolicyStatement.
   Such policies define a goal to be achieved, or a set of actions to
   take, but do not prescribe how to achieve the goal or execute the
   actions. This differentiates it from a SUPAECAPolicyRule, which
   explicitly defines what triggers the evaluation of the
   SUPAECAPolicyRule, what conditions must be satisfied in order to
   execute the actions of the SUPAECAPolicyRule, and what actions to
   execute.








Strassner                 Expires January 4, 2016            [Page 11]


Internet-Draft            SUPA Generic Policy Model          July 2015

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) that it is attached to. 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
   SUPAPolicyStatement. 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. SUPAPolicySubject

   SUPAPolicySubject is an abstract class that defines a set of
   managed objects that authored this SUPAPolicyStatement. This is
   required for auditability. A SUPAPolicySubject may use one or more
   mechanisms to identify the set of managed objects that authored it;
   examples include OIDs and URIs.

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








Strassner                 Expires January 4, 2016            [Page 12]


Internet-Draft            SUPA Generic Policy Model          July 2015


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 [RFC3060] and [RFC3460].

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

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.

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.




Strassner                 Expires January 4, 2016            [Page 13]


Internet-Draft            SUPA Generic Policy Model          July 2015


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.
   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.

   In an information model, a composition MAY be represented as
   a class.

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 have a restriction on the ability of an object
   at one end of the relationship to access the object at the other
   end of the relationship. 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. In this example, the arrow would be pointing
          at object B.


Strassner                 Expires January 4, 2016            [Page 14]


Internet-Draft            SUPA Generic Policy Model          July 2015


3.2.3.9. Abstract Class

   An abstract class is a class that cannot be directly instantiated.


3.2.3.10. Concrete Class

   A concrete class is a class that can be directly instantiated.


3.2.4.  Mathematical Logic Terminology

   This section defines terminology for mathematical logic.

3.2.4.1. Predicate

   A predicate is a Boolean-valued function (i.e., a function whose
   values are interpreted as either TRUE or FALSE, depending on the
   values of its variables).

3.2.4.2. Logic Operators

   A logical connective is a symbol or word that defines how to
   connect two or more sentences in a language.

3.2.4.2.1. Propositional Logic Connectives

   There are five propositional logic connectives, defined as follows:

     o Negation, or a logical NOT operator, is an operation that,
       when applied to a proposition, produces a new proposition
       "not p", which has the opposite truth value of p.
     o Conjunction, or a logical AND operator, is an operation on two
       logical values that produces a value of TRUE if and only if
       both of its operands are TRUE.
     o Disjunction, or a logical OR operator, is an operation on two
       logical values that produces a value of FALSE if and only if
       both of its operands are FALSE.
     o Implication, or the conditional operator, is used to form
       statements of the form "if <proposition A> is TRUE, then
       <proposition B> is also TRUE (i.e., this statement is FALSE
       only when A is TRUE and B is FALSE).
     o Bi-implication, or the bi-conditional operator, is used to
       form statements of the form "<proposition A> is TRUE if and
       only if <proposition B> is TRUE (i.e., this statement is TRUE
       if and only if both propositions are FALSE or if both
       propositions are TRUE).




Strassner                 Expires January 4, 2016            [Page 15]


Internet-Draft            SUPA Generic Policy Model          July 2015


3.2.4.2.2. First Order Logic Quantifiers

   This document defines two types of quantifiers for First Order
   Logic statements.

   Quantification specifies the number of objects that satisfies a
   formula. This document uses two such quantifiers, which are
   defined as follows:

     o Universal quantification asserts that a predicate within the
       scope of this operator is TRUE of every value of a variable of
       the predicate. It is commonly interpreted as "for all".
     o Existential quantification asserts that a predicate within the
       scope of this operator is TRUE for at least one value of a
       variable of the predicate. It is commonly interpreted as
       "there exists, "there is at least one", or "for some".


3.2.4.3. Propositional Logic

   Propositional Logic (PL) may be simply defined as a language
   consisting of a set of statements; the value of each statement is
   either TRUE or FALSE. More formally, a (propositional) Argument
   consists of a sequence of Premises and a Conclusion. An Argument is
   valid if the Conclusion is TRUE whenever all Premises are TRUE.

   PL may be thought of as a set of declarative propositions.


3.2.4.4. First-Order Logic

   First-Order Logic (FOL) may be simply defined as a language
   consisting of a set of statements; each statement is a predicate.

   A predicate is a Boolean-valued function (i.e., the value of the
   function evaluates to either TRUE or FALSE, depending on the value
   of its variables). Predicates can also be compared.

   FOL uses quantified variables. The universal quantifier and/or the
   existential quantifier can be used to define what values can be
   instantiated by the predicated variables.










Strassner                 Expires January 4, 2016            [Page 16]


Internet-Draft            SUPA Generic Policy Model          July 2015


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




Strassner                 Expires January 4, 2016            [Page 17]


Internet-Draft            SUPA Generic Policy Model          July 2015


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. Logical Connectives

   The following defines a mapping between the typical mathematical
   symbols used for logical connectives (most of which are in
   extended ASCII) and the symbols that will be used in this document.

      Connective       ASCII CODE   UNICODE Code  Meaning
      Negation         172          U+00AC        "NOT"
      Conjunction      8743         U+2227        "AND"
      Disjunction      8744         U+2228        "OR"
      Implication      8658         U+21D2        "IMPLIES"
      Bi-implication   8660         U+21D4        "IF AND ONLY IF"

3.3.7. Quantifiers

   The following defines a mapping between the typical mathematical
   symbols used for quantifiers and the symbols that will be used in
   this document.

      Quantifier      ASCII Code   Unicode Code   Symbol Used
      Universal       8704         U+2200         "FOR ALL"
      Existential     8707         U+2203         "THERE EXISTS"

Strassner                 Expires January 4, 2016            [Page 18]


Internet-Draft            SUPA Generic Policy Model          July 2015


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 This version of this document restricts the expression of
        Policy to
          o a set of event-condition-action tuples
          o a set of PL or FOL statements
          o a combination of ECA rules and PL or FOL statements.
      o Since these representations are very different in syntax and
        content, the content of a Policy is abstracted from its
        representation:
          o SUPAECAPolicyRules and SUPALogicStatements are each types
            of SUPAPolicies
          o SUPAECAPolicyRules and SUPALogicStatements are both
            constructed from SUPAPolicyStatements
          o A SUPAPolicy MAY use SUPAECAPolicyRules and/or
            SUPALogicStatements
          o A SUPAPolicy consists of one or more SUPAPolicyStatements,
            and optionally may specify one or more SUPAPolicyTarget,
            SUPAPolicySubject, and SUPAPolicyMetadata objects
      o A SUPAPolicyStatement has three subclasses:
          o a SUPABooleanClause for building SUPAECAPolicyRules from
            reusable objects
          o a SUPALogicClause for building SUPALogicStatements from
            reusable objects
          o a SUPAENcodedClause for using attributes instead of
            objects to construct a SUPAECAPolicyRule or a
            SUPALogicStatement
      o A SUPAPolicy MUST contain at least one SUPAPolicyStatement.
      o A SUPAECAPolicyRule defines the set of events and conditions
        that are responsible for executing its actions; it MUST have
        an event clause, a condition clause, and an action clause.
      o A SUPALogicStatement expresses facts that it believes to be
        true without defining how those facts are computed, and
        provides an efficient query mechanism for retrieving facts.
        Each SUPAPolicyStatement MUST be expressed as a function-free
        Horn clause; there are a number of additional restrictions
        that are covered in Section 7.
      o SUPAMetadata MAY be defined for any type of
        SUPAPolicyStatement (as well as for individual objects that
        make up a SUPAPolicyStatement).
      o SUPAMetadata MAY be prescriptive and/or descriptive in nature.
      o A SUPAPolicyTarget is a set of managed objects that the
        actions of the SUPAPolicy are applied to.
      o A SUPAPolicySubject is a set of managed objects that authored
        the SUPAPolicy.

Strassner                 Expires January 4, 2016            [Page 19]


Internet-Draft            SUPA Generic Policy Model          July 2015


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.

   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.



Strassner                 Expires January 4, 2016            [Page 20]


Internet-Draft            SUPA Generic Policy Model          July 2015


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 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 more formal form (e.g.,
   Datalog (as in OpenStack Congress) or a set of
   SUPALogicStatements). 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 understand. 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 1 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 defines a set of objects that define the
   key elements of a Policy independent of how it is represented or
   its content. As will be shown, there is a significant difference
   between SUPAECAPolicyRules (see Section 6) and SUPALogicStatements
   (see Section 7). In principle, other types of SUPAPolicies could
   be defined, but the current charter is restricted to using these
   two types of SUPAPolicies as exemplars.


Strassner                 Expires January 4, 2016            [Page 21]


Internet-Draft            SUPA Generic Policy Model          July 2015


           +----------------------------------------------+
           | SUPA Generic Policy Information Model (GPIM) |
           +----------------------+-----------------------+
                                 / \
                                  |
                                  |
                +-----------------+--------------+
                |                                |
                |                                |
    +-----------+---------------+  +-------------+------------+
    |    SUPAECAPolicyRule      |  |   SUPA Logic Statement   |
    | Information Model (EPRIM) |  | Information Model (LSIM) |
    +-----------+---------------+  +-------------+------------+
               / \                              / \
                |                                |
                |                                |
    +-----------+-----------+        +-----------+------------+
    |     ECAPolicyRule     |        |    Logic Statement     |
    |       Data Model      |        |       Data Model       |
    +-----------------------+        +------------------------+

          Figure 1: Overview of SUPA Policy Rule Abstractions


   The GPIM defines the following concepts:

     o SUPAPolicy:          the root of the SPGIM model
     o SUPAPolicyAtomic:    a Policy that can be used in a stand-alone
                            manner
     o SUPAPolicyComposite: used to build hierarchies of Policies
     o SUPAPolicyStatement: used to define the content of a SUPAPolicy
     o SUPAPolicyTerm:      used to define variables, operators, and
                            values in a SUPAPolicyStatement
     o SUPAPolicySubject:   the author of a SUPAPolicy
     o SUPAPolicyTarget:    the managed object that a SUPAPolicy
                            monitors and/or controls the state of
     o SUPAPolicyMetadata:  specifies descriptive and/or prescriptive
                            information about a SUPAPolicy object

   A SUPAPolicy object serves as a single root of the SUPA system
   (i.e., all other classes in the model are subclasses of the
   SUPAPolicy class). This simplifes code generation and reusability.
   Note that this is NOT true of either [4] or [6]; it is true of [2].

   SUPA Policies are defined as either a stand-alone or a hierarchy
   of PolicyContainers. A PolicyContainer specifies the structure,
   content, and optionally, subject, target, and metadata information
   for the Policy.



Strassner                 Expires January 4, 2016            [Page 22]


Internet-Draft            SUPA Generic Policy Model          July 2015


   A SUPAPolicy takes one of two forms: (1) an ECA Policy, and/or
   (2) a declarative set of statements. The GPIM enables both types
   of policies to be combined; this is also true of [2] and [5].
   However, this is not true of [4] and [6], since neither define
   declarative policies (additional reasons are beyond the scope of
   this document).

   The GPIM design enables a Policy of one type to invoke Policies
   of the other type. For example, a declarative policy may directly
   or indirectly invoke one or more ECA policies. Since declarative
   policies are at a higher level of abstraction, this is the typical
   case, though it is possible for the reverse to occur. For example,
   an ECA policy could invoke a declarative policy as one of its
   actions if it is more appropriate to specify a generic, as opposed
   to a prescriptive, course of action. This is also true of [2] and
   [5]; however, this is not true of [4] and [6], since neither
   define declarative policies (additional reasons are beyond the
   scope of this document).

   Both a SUPAECAPolicyRule and a SUPALogicalStatement are made up of
   one or more SUPAPolicyStatements, which define the content of the
   Policy. Three types of SUPAPolicyStatements are available; one is
   generic, and can be used by any type of Policy, while the other
   two are specific to an ECA or a declarative Policy, respectively.
   The generic SUPAPolicyStatement, called SUPAEncodedClause, encodes
   the policy as an attribute. In contrast, the two specific types of
   SUPAPolicyStatements (SUPABooleanClause and SUPALogicClause, which
   are used for ECA and declarative policies, respectively), typically
   are made up of (reusable) SUPAPolicy objects. All three may thus be
   constructed at runtime by a machine. This is also true of [2] and
   [5]; however, this is not true of [4] and [6], since both lack
   the abstraction of a common PolicyStatement.

   A SUPAPolicyStatement may be made up of SUPAPolicyTerms, which
   enables a clause to be defined in a canonical {variable, operator,
   value} form. In addition, specific objects for constructing ECA
   Policies and declarative Policies are also provided. This is
   provided to enable machine-driven construction of policies.

   This set of classes enables each different types of Policies to be
   defined by an information model that refines the generic concepts
   of the GPIM as described above. For example, a SUPAECAPolicyRule,
   as well as a SUPALogicStatement, are both subclasses of the
   SUPAPolicyAtomic class. Therefore, both can be used as part of a
   hierarchy of Policies or in a stand-alone manner. As another
   examples, a SUPALogicClause and a SUPABooleanClause are both
   subclasses of SUPAPolicyStatement, and are used to create
   SUPALogicStatements and SUPAECAPolicyRules, respectively.



Strassner                 Expires January 4, 2016            [Page 23]


Internet-Draft            SUPA Generic Policy Model          July 2015


4.4. Structure of SUPA Policies

   This section describes the overall design of the GPIM.

4.4.1. ECA Policy Rule Structure

   A SUPAECAPolicyRule is a statement that consists of an event
   clause, a condition clause, and an action clause. This type of
   Policy explicitly defines the current and desired states of the
   system being managed. Conceptually, it is represented as follows:

      +------------------+            +---------------------+
      | SUPAPolicyAtomic |            | SUPAPolicyStatement |
      +---------+--------+            +----------+----------+
               / \                              / \
                I                                I
                I                                I
                I                                I
                I               +----------------+------------------+
   +------------+------------+  |       SUPABooleanClause or        |
   |    SUPAECAPolicyRule    |  |         SUPAEncodedClause         |
   +------+-------+-------+--+  +------+-----------+-----------+----+
     0..1/ \ 0..1/ \ 0..1/ \          / \         / \         / \
          A       A       A            I           I           I
         \ /     \ /     \ /           I           I           I
          |       |       |       +----+---+       I           I
          |       |       |       |  Event |       I           I
          |       |       |       | Clause | +-----+-----+     I
          |       |       |       +------+-+ | Condition |     I
          |       |       |         1..n/ \  |   Clause  | +---+----+
          |       |       |              |   +-------+---+ | Action |
          |       |       |              |      1..n/ \    | Clause |
          |       |       |              |           |     +-----+--+
          |       |       |              |           |      1..n/ \
          |       |       +--------------+           |           |
          |       |        HasSUPAEvents             |           |
          |       |                                  |           |
          |       +----------------------------------+           |
          |                   HasSUPAConditions                  |
          |                                                      |
          +------------------------------------------------------+
                                  HasSUPAActions


          Figure 2: Overview of SUPA Policy Rule Abstractions

   Note that the event, condition, and action clauses may be defined
   by using SUPABooleanClauses or SUPAEncodedClauses. See section 6.5
   for the former and 5.5 (especially 5.5.2.1) for the latter.


Strassner                 Expires January 4, 2016            [Page 24]


Internet-Draft            SUPA Generic Policy Model          July 2015


4.4.2. Logical Statement Structure

   A SUPALogicStatement is either a set of PL or FOL statements.
   These are called SUPAPLStatement and SUPAFOLStatement,
   respectively.

   A SUPAPLStatement is a set of propositions that form a (single)
   conclusion. A proposition is either TRUE or FALSE. A proposition
   be created from simpler propositions combined using Propositional
   Logic Connectives (see Section Propositions (see Section
   3.2.4.2.1.). It may be conceptualized as follows:

                     +---------------------+
                     | SUPAPLogicStatement |
                     +-----------+---------+
                                / \
                                 I
                                 I
                                 I
                        +--------+--------+
                        | SUPAPLStatement |
                        +--------+--------+
                                / \
                                 I
                                 I
              +------------------+--+--------------------+
              I                     I                    I
              I                     I                    I
              I                     I                    I
      +-------+-------+   +---------+--------+  +--------+-------+
      | SUPAPLPremise |   | SUPAPLConclusion |  | SUPAPLArgument |
      +---------+-----+   +----------+-------+  +-----+--------+-+
          1..n / \                1 / \          0..1/ \  0..1/ \
                |                    |                A        A
                |                    |                |        |
                |                    |                |        |
                |                    +----------------+        |
                |                   HasSUPAPLConclusion        |
                |                                              |
                +----------------------------------------------+
                               HasSUPAPLPremises


     Figure 3: Overview of SUPA Propositional Logic Abstractions

   As shown in Figure 4, a SUPAPLArgument consists of a set of one
   or more SUPAPLPremises and a single SUPAPLConclusion. The
   multiplicity of the two aggregations is 0..1 on the aggregate
   side to enable SUPAPLPremises and SUPAPLConclusions to be created
   and stored indepedent of being used in a SUPAPLArgument.

Strassner                 Expires January 4, 2016            [Page 25]


Internet-Draft            SUPA Generic Policy Model          July 2015


   In PL, each possible atomic fact requires a separate propositional
   symbol. This can lead to a large amount of premises required to
   form a conclusion.

   FOL provides a richer knowledge representation by using:

      o objects (i.e., terms), which define individual entities
      o properties (i.e., unary predicates on terms), which
        distinguishes objects from each other
      o relations (i.e., n-ary predicates on terms), which define
        facts among a set of objects, and
      o functions (i.e., the mapping from one set of terms to another
        set of terms).

   FOL may be conceptualized as follows:

                        +---------------------+
                        | SUPAPLogicStatement |
                        +-----------+---------+
                                   / \
                                    I
                                    I
                                    I
                          +---------+--------+
                          | SUPAFOLStatement |
                          +---------+--------+
                                   / \
                                    I
                                    I
                                    I
                     +--------------+------------+
                     I                           I
                     I                           I
                     I                           I
             +-------+------+            +-------+------+
             | SUPAGoalBody |            | SUPAGoalHead |
             +---------+----+            +-------+------+
                 1..n / \                   0..1/ \
                       |                         A
                       |                         |
                       |                         |
                       +-------------------------+
                           HasSUPAGoalBody


      Figure 4: Overview of SUPA First Order Logic Abstractions





Strassner                 Expires January 4, 2016            [Page 26]


Internet-Draft            SUPA Generic Policy Model          July 2015


   FOL Syntax may be described using the following grammar:

      Sentence
        : AtomicSentence
        | Sentence Connective Sentence
        | (Quantifier Variable)+ Sentence
        | 'NOT' Sentence
        | function '(' Sentence ')'
        ;


4.5. GPIM Assumptions

   Most policy models (e.g., [2], [4], [5], and [6]) are built as part
   of an overarching model. SUPA DOES NOT assume that it is the "root
   class of everything". Rather, the SUPA information model is built
   as a single inheritance model fragment to accommodate inserting the
   SUPA model into another model (e.g., the root of the SUPA model
   becomes a subclass of the other model). This is shown in Figure 5.


             +------------------------------------------+
             |     Root Class of an Existing Model      |
             +--------------------+---------------------+
                                 / \
                                  I
                                  I
                                  I
                +-----------------+--------------+
                I                                I
                I                                I
                I                                I
    +-----------+-----------+       +------------+------------+
    |    A Subclass of the  |       | Another Subclass of the |
    |     Existing Model    |       |      Existing Model     |
    +-----------------------+       +------------+------------+
                                                / \
                                                 I
                                                 I
                                                 I
                                     +-----------+------------+
                                     |  SUPA Class Hierarchy  |
                                     |   (GPIM plus EPRIM     |
                                     |      and/or LSIM)      |
                                     +------------------------+

          Figure 5: Integrating SUPA into an Existing Model




Strassner                 Expires January 4, 2016            [Page 27]


Internet-Draft            SUPA Generic Policy Model          July 2015



4.6. Scope of Previous Work

   Insert intro paragraph and reference SUPA Gap Analysis [6]. Some
   salient points on previous policy models:

      o [RFC3060] and [RFC3460] only define a policy rule that
        consists of a condition clause and an action clause; it does
        not define an ECA policy rule, nor does it define a
        LogicStatement
      o [4] is more elaborate than [RFC3060] and [RFC3460], but
        suffers from the same limitations
      o [5] defines four types of policies (i.e., ECA, Goal,
        UtilityFunction, and Promise), but does not have the detail
        defined in this document

   Rest to be finished. Sections will include:

      o Description of, and problems with, [RFC3060]
      o Description of, and problems with, [RFC3460]
      o Should this section also talk about CIM or SID? I personally
        think that this should be in the gap analysis...





























Strassner                 Expires January 4, 2016            [Page 28]


Internet-Draft            SUPA Generic Policy Model          July 2015


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

5.1. Overview
   The overall class definition is shown in Figure 6. SUPAPolicy is
   the root of the SUPA class hierarchy. For implementations, it is
   assumed that SUPAPolicy is subclassed from a class from another
   model. In Figure 6, indentation represents subclassing.


   (Class of another model that SUPA is integrating into)
       |
       +---SUPAPolicy (see Section 5.2)
             |
             +---SUPAPolicyAtomic (see Section 5.3)
             |
             +---SUPAPolicyComposite (see Section 5.4)
             |
             +---SUPAPolicyStatement (see Section 5.5)
             |
             +---SUPAPolicySubject (see Section 5.6)
             |
             +---SUPAPolicyTarget (see Section 5.7)
             |
             +---SUPAPolicyTerm (see Section 5.8)
             |
             +---SUPAPolicyMetadata (see Section 5.9)


           Figure 6: Main Classes of the GPIM

   The following subsections define the classes of the GPIM. If a
   class has attributes, those attributes are also defined.
   Relationships are defined according to the class that is the
   "owner", or primary actor, participating in the relationship.

   Classes, attributes, and relationships that are marked as
   "mandatory" MUST be part of a conformant implementation. Classes,
   attributes, and relationships that are marked as "optional"
   SHOULD be part of a conformant implementation.


5.2. The Abstract Class "SUPAPolicy"

   This is a mandatory abstract class. This class is the root of the
   SUPA class hierarchy. It defines the common attributes and
   relationships that all SUPA subclasses inherit. SUPAPolicy was
   abstracted from DEN-ng [2], and a version of this class is in the
   process of being added to the policy framework defined in [5].


Strassner                 Expires January 4, 2016            [Page 29]


Internet-Draft            SUPA Generic Policy Model          July 2015


   A SUPAPolicy takes the form of an individual policy or a set of
   policies. The former is defined by an instance of a concrete
   subclass of the SUPAPolicyAtomic class. The latter consists of a
   set of PolicyContainers; each PolicyContainer is an instance of a
   SUPAPolicyComposite (or a subclass of it). Each SupaPolicyComposite
   can have zero or more instances of a concrete subclass of the
   SUPAPolicyAtomic class.

   In this approach, a SUPAPolicyAtomic class is the superclass of
   SUPAECAPolicyRule and SUPALogicStatement. These two classes define
   the type of policy that is being defined. A SUPAPolicyComposite is
   a PolicyContainer with SUPAMetadata attached. Each PolicyContainer
   forms its own containment hierarchy, and SUPAMetadata can be used
   to describe and/or prescribe how policies behave within each
   PolicyContainer.

   Each SUPAPolicyAtomic object (or a subclass of it) MUST have at
   least one SUPAPolicyStatement that is used to define the content
   of the policy. Some types of policies, such as an ECA policy rule,
   MUST have at least three SUPAPolicyStatements, one each to define
   its event, condition, and action clauses. SUPALogicStatements
   typically have multiple SUPAPolicyStatements.

   A SUPAPolicy MAY be qualified (i.e., may aggregate these objects
   to more completely specify the behavior of the SUPAPolicy) by a
   set of zero or more SUPAPolicySubjects, SUPAPolicyTargets, and/or
   SUPAPolicyMetadata objects. Note that these three classes are
   defined as abstract, in order to simplify mapping to, and
   optimization of, data models. When defined in an information model,
   the SUPAPolicyAtomic and SUPAPolicyComposite classes MUST have
   separate aggregation relationships with the SUPAPolicySubject and
   SUPAPolicyTarget objects (or their subclasses), if these objects
   are defined. Any subclass of SUPAPolicy that wants to use metadata
   MUST have one or more separate aggregation relationships with a
   SUPAPolicyMetadata class (or its subclasses). When implemented in
   a data model, the set of SUPAPolicyStatement, SUPAPolicyTarget,
   SUPAPolicySubject, and SUPAPolicyMetadata object instances SHOULD
   all be part of a single PolicyContainer object. They MAY be
   translated to a more efficient form (e.g., flattening the objects
   that are participating in the above relationships into a single
   object instance).

   Figure 7 shows the SUPAPolicy class, and two of its subclasses
   (SUPAPolicyAtomic and SUPAPolicyComposite). This is an
   implementation of the composite pattern [3], which enables a
   SUPAPolicy to be made up of a stand-alone object (an instance of a
   SUPAPolicyAtomic class) or a hierarchy of objects (i.e., instances
   of one or more SUPAPolicyAtomic and SUPAPolicyComposite classes).
   The use of this software pattern enables SUPA Policies to be
   designed as individual objects and/or hierarchies of objects.

Strassner                 Expires January 4, 2016            [Page 30]


Internet-Draft            SUPA Generic Policy Model          July 2015


                      +-------------------------------+
                      | Parent Class of another Model |
                      +--------------+----------------+
                                    / \
      +---------------------+        I
      | HasSUPAPolicyDetail |        I
      +-----+---------------+        I
            ^                        I
            |   1..n +---------------+----------------+
            |       \|                                |
       +----+--------+           SUPAPolicy           |
       |            /|                                |
       |             +---------------+----------------+
       |                            / \
       |                             I
       | HasSUPAPolicies             I
       |                             I
       |                             I
       |                 +-----------+----------+
       |                 |                      |
       |                 |                      |
       | 0..1 +----------+----------+ +---------+--------+
       |   / \|                     | |                  |
       +--- A + SUPAPolicyComposite | | SUPAPolicyAtomic |
           \ /|                     | |                  |
              +---------------------+ +------------------+

              Figure 7: The SUPAPolicy Class Hierarchy

   Note that a SUPAPolicy, as well as a SUPAPolicyAtomic and a
   SUPAPolicyComposite, are all PolicyContainer objects. SUPAPolicy
   was abstracted from DEN-ng [2], and a version of this class is in
   the process of being added to the policy framework defined in the
   TM Forum ZOOM model [5].

   In figure 7:

      o Both SUPAPolicyComposite and SUPAPolicyAtomic inherit from
        SUPAPolicy
      o The diamond with an enclosed "A" represents an aggregation
        (see Section 3.2.3.4)
      o The HasSUPAPolicies aggregation is implemented as an
        association class (see Section 3.2.3.6)
      o The multiplicity of the HasSUPAPolicies aggregation is
        0..1 - 1..n (zero or one SUPAPolicyComposite object instances
        can aggregate one or more SUPAPolicy object instances, see
        Section 3.2.3.7)
      o The arrow pointing at SUPAPolicy restricts the navigability
        of this aggregation (see Section 3.2.3.8)


Strassner                 Expires January 4, 2016            [Page 31]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.2.1. SUPAPolicy Attributes

   This section defines the attributes of the SUPAPolicy class. These
   attributes are inherited by all subclasses of the SUPAPolicy class.

5.2.1.1. The Attribute "supaObjectIDContent"

   This is a mandatory attribute that represents part of the object
   identifier of an instance of this class. It is a string attribute,
   and defines the content of the object identifier. It works with
   another class attribute, called supaObjectIDFormat, 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].

   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. In this
   way, different naming schemes, such as those depending on URIs,
   FQDNs, primary key - foreign key relationships, and UUIDs can all
   be accommodated.

5.2.1.2. The Attribute "supaObjectIDFormat"

   This is a mandatory attribute that represents part of the object
   identifier of an instance of this class. It is a string attribute,
   and defines the format of the object identifier. It works with
   another class attribute, called supaObjectIDContent, 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.
   This is based on the DEN-ng class design [2].

5.2.1.3. The Attribute "supaPolicyDescription"

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

5.2.1.4. 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 [RFC3060], as that attribute is intended to be used
   with just X.500 cn attributes.



Strassner                 Expires January 4, 2016            [Page 32]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.2.2. SUPAPolicy Relationships

   This section defines the relationships of the SUPAPolicy class.

5.2.2.1. The Relationship "SUPAPolicyMetadata"

   This is a mandatory aggregation that defines the set of
   SUPAPolicyMetadata that are aggregated by this particular
   SUPAPolicy object. The multiplicity of this relationship is defined
   as 0..1 on the aggregate (SUPAPolicy) side, and 0..n on the part
   (SUPAPolicyMetadata) side. This means that this relationship is
   optional, but if it is instantiated, then one or more SUPAPolicy
   objects are contained in this particular SUPAPolicyComposite
   object. The semantics of this aggregation are implemented using
   the SUPAPolicyMetadataDetail association class.

5.2.2.2. The Association Class "SUPAPolicyMetadataDetail"

   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 SUPAPolicy object instance.

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


5.3. The Abstract Class "SUPAPolicyAtomic"

   This is a mandatory abstract class. This class is a type of
   PolicyContainer. SUPAPolicyAtomic was abstracted from DEN-ng [2],
   and a version of this class is in the process of being added to
   the policy framework defined in the TM Forum ZOOM model [5].

   A SUPAPolicyAtomic class represents a SUPA Policy that can operate
   as a single, stand-alone, manageable object. Put another way, a
   SUPAPolicyAtomic object can NOT be modeled as a set of hierarchical
   SUPAPolicy objects; if this functionality is required, then a
   SUPAPolicyComposite object must be used.

   The SUPAPolicyAtomic class is the superclass for the different
   types of SUPA Policies that are defined. In this release, both a
   SUPAECAPolicyRule (see Section 6) as well as a SUPALogicStatement
   (see Section 7) are defined as its subclasses.







Strassner                 Expires January 4, 2016            [Page 33]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.3.1. SUPAPolicyAtomic Attributes

   This section defines the attributes of the SUPAPolicyAtomic class.

   Care must be taken in adding attributes to this class, because the
   behavior of SUPALogicStatements is very different than the behavior
   of SUPAECAPolicyRules.

5.3.1.1. The Attribute "supaPolicyDeployStatus"

   This is an optional attribute, which is an enumerated,
   non-negative integer. It defines the current deployment status of
   this SUPAECAPolicyRule. Both operational and test mode values are
   included in its definition. Values include:

      0:  undefined
      1:  deployed and enabled
      2:  deployed and in test
      3:  deployed but not enabled
      4:  ready to be deployed
      5:  not deployed

5.3.1.2. The Attribute "supaPolicyExecStatus"

   This is an optional attribute, which is an enumerated,
   non-negative integer that defines the current execution status of
   this SUPAECAPolicyRule. Both operational and test mode values are
   included in its definition. Values include:

      0:  undefined
      1:  executed and SUCEEDED (operational mode)
      2:  executed and FAILED (operational mode)
      3:  currently executing (operational mode)
      4:  executed and SUCEEDED (test mode)
      5:  executed and FAILED (test mode)
      6:  currently executing (test mode)

5.3.2. SUPAPolicyAtomic Relationships

   This section defines the relationships of the SUPAPolicyAtomic
   class.

5.3.2.1. The Aggregation "SUPAPAHasPolicyStmts"

   This is a mandatory aggregation that defines the set of
   SUPAPolicyStatements that MUST be aggregated by this particular
   SUPAPolicyAtomic object. The multiplicity of the aggregation is
   0.n on the aggregate (SUPAPolicyAtomic) side, and 1..n on the part
   (SUPAPolicyStatement) side.


Strassner                 Expires January 4, 2016            [Page 34]


Internet-Draft            SUPA Generic Policy Model          July 2015


   The "0..n" part of the multiplicity enables SUPAPolicyStatements to
   be stored in a repository for later use, while the "1..n" part of
   the multiplicity mandates that at least one SUPAPolicyStatement
   MUST be aggregated by this particular SUPAPolicyAtomic object. More
   specifically, a cardinality of "3..n" on the part side is
   incorrect, since that would also apply to SUPALogicStatements. The
   semantics of this aggregation are defined by the
   SUPAPAHasPolicyStmtDetail association class.

5.3.2.2. The Association Class "SUPAPAHasPolicyStmtDetail"

   This is an association class, and defines the semantics of the
   SUPAPAHasPolicyStmts aggregation. This enables the attributes and
   relationships of the SUPAPAHasPolicyStmtDetail class to be used to
   constrain which SUPAPolicyStatements objects can be aggregated by
   this particular SUPAPolicyAtomic object instance. Attributes will
   be added to this class at a later time.


5.4. The Concrete Class "SUPAPolicyComposite"

   This is a mandatory concrete class. This class is a type of
   PolicyContainer. SUPAPolicyComposite was abstracted from DEN-ng
   [2], and a version of this class is in the process of being added
   to the policy framework defined in the TM Forum ZOOM model [5].

   A SUPAPolicyComposite class represents a SUPA Policy as a
   hierarchy of Policy objects, where the hierarchy contains
   instances of a SUPAPolicyAtomic and/or SUPAPolicyComposite
   object. Each of the SUPA Policy objects, including the outermost
   SUPAPolicyComposite object, are separately manageable. More
   importantly, the SUPAPolicyComposite object can aggregate any
   SUPAPolicy subclass. Hence, it can be used to form hierarchies of
   SUPAPolicies as well as associate SUPAPolicySubjects and/or
   SUPAPolicyTargets to a given SUPAPolicy.

5.4.1. SUPAPolicyComposite Attributes

   This section defines the attributes of the SUPAPolicyComposite
   class. The combination of these two attributes provides a more
   flexible and powerful solution compared to [RFC3060] and [RFC3460].

   Care must be taken in adding attributes to this class, because the
   behavior of SUPALogicStatements is very different than the behavior
   of SUPAECAPolicyRules.






Strassner                 Expires January 4, 2016            [Page 35]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.4.1.1. The Attribute "supaPCFailureStrategy"

   This is an optional non-negative enumerated integer attribute,
   whose values are used to define what action(s) should be taken if
   a failure occurs when executing a SUPAPolicy object that is
   contained in this SUPAPolicyComposite object. Values include:

      0:  undefined
      1:  stop execution
      2:  attempt rollback on failed policy
      3:  attempt rollback on all policies
      4:  ignore failure and continue

   A value of 0 can be used as an error condition. A value of 1 means
   that ALL execution is stopped, and that other SUPAPolicies that
   otherwise would have been executed are ignored. A value of 2 means
   that execution is stopped, and a rollback of that SUPAPolicy (and
   ONLY that SUPAPolicy) is attempted. A value of 3 means that
   execution is stopped, and all SUPAPolicies that have been
   previously executed (including the one that just failed) are
   rolled back. A value of 4 means that any failure will be ignored,
   and all SUPAPolicies contained in this SUPAPolicyComposite object
   will be executed.

5.4.1.2. The Attribute "supaPCIsMatchAll"

   This is an optional Boolean attribute. If its value is TRUE, then
   ALL SUPAPolicies that are contained in this SUPAPolicyComposite
   object will be evaluated, regardless of whether a SUPAPolicy fails
   to execute correctly or not. If its value is FALSE, then only the
   FIRST SUPAPolicy contianed in this SUPAPolicyComposite object will
   be evaluated. The default value is TRUE.

5.4.2. SUPAPolicyComposite Relationships

   This section defines the relationships of SUPAPolicyComposite.

5.4.2.1. The Aggregation "HasSUPAPolicies"

   This is a mandatory aggregation that defines the set of
   SUPAPolicies that are contained in the instance of this
   particular SUPAPolicyComposite object. The multiplicity of this
   relationship is defined as 0..1 on the aggregate
   (SUPAPolicyComposite) side, and 1..n on the part (SUPAPolicy) side.
   This means that this relationship is optional, but if it is
   instantiated, then one or more SUPAPolicy objects are contained in
   this particular SUPAPolicyComposite object. The semantics of this
   aggregation are implemented using the HasSUPAPolicyDetail
   association class.


Strassner                 Expires January 4, 2016            [Page 36]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.4.2.2. The Association Class "HasSUPAPolicyDetail"

   This is a mandatory concrete association class that defines the
   semantics of the HasSUPAPolicies aggregation. This enables the
   attributes and relationships of the HasSUPAPolicyDetail class to
   be used to constrain which SUPAPolicy objects can be aggregated
   by this particular SUPAPolicyComposite object instance.
   Attributes will be added to this class at a later time.


5.5. The Abstract Class "SUPAPolicyStatement"

   This is a mandatory abstract class that separates the
   representation of a SUPAPolicy from its implementation. This
   abstraction is missing in [RFC3060], [RFC3460], [4], and [6].
   SUPAPolicyStatement was abstracted from DEN-ng [2], and a version
   of this class is in the process of being added to the policy
   framework defined in the TM Forum ZOOM model [5].

   A SUPAPolicyStatement contains an individual or group of related
   functions that are used to build different types of policies. This
   is implemented using the composite pattern [3], so hierarchies of
   SUPAPolicyStatements can be constructed. Note that the hierarchy
   is available for two of its three subclasses: SUPABooleanClause
   (which is for forming ECA policy rules) and SUPALogicClause (which
   is for forming declarative policies). SUPAEncodedClause does not
   need to use this pattern, since it already encoded the clause.

   This document defines three different types of policies: ECA policy
   rules, declarative policies, and encoded policies. These different
   types of policies can be used to define a goal to be achieved, a
   set of facts to be used, or a set of actions to take. Examples of
   actions include getting data from network elements or other
   sources, stating facts about the system being managed, writing a
   change to a configuration of one or more managed objects, and
   querying information about one or more managed objects.

   SUPAPolicyStatements are objects in their own right, which
   facilitates their reuse. SUPAPolicyStatements can aggregate a set
   of SUPAPolicyTerms and/or a set of SUPAECAComponents. The former
   enables a SUPAPolicyStatement to be constructed from a set of
   SUPAPolicy objects, which emphasizes reusability and facilitates
   machine-directed policy authoring. The latter enables a higher
   level of abstraction to be applied to SUPAECAPolicyRules (i.e.,
   the Event, Condition, and Action clauses can be filled by the
   subclasses OF SUPAECAComponents (SUPAEvent, SUPACondition, and
   SUPAAction).




Strassner                 Expires January 4, 2016            [Page 37]


Internet-Draft            SUPA Generic Policy Model          July 2015


   SUPAPolicyStatements can also be aggregated by a SUPAPolicyAtomic
   object - this enables both ECA policy rules and declarative policy
   statements to use SUPAPolicyStatements to form their policy rules.

   A class diagram showing SUPAPolicyStatement is shown in Figure 8.

                                            +---------------------+
                                            | HasSUPAPolicyDetail |
                                            +----------+----------+
                                                       ^
                            +-----------------+        |
                            |                 |/       |
    +------------------+    |    SUPAPolicy   +--------+------+
    | SUPAPolicyAtomic |    |                 |\              |
    +--------+---------+    +---------+-------+ 1..n          |
       0..n / \                      / \                      |
             A                        I                       |
            \ /                       I       HasSUPAPolicies |
             |                        I                       |
             | SUPAPAHasPolicyStmts   I                       |
             |                        I                       |
             |     +------------------+------+-----------+    |
             |     I                         I           I    |
       1..n \ /    I                         I           I    |
     +-------+-----+-------+      +----------+-------+   I    |
     | SUPAPolicyStatement |      | SUPAPolicyAtomic |   I    |
     +-------+----+--------+      +------------+-----+   I    |
            / \  / \ 1..n                0..n / \        I    |
             I    |                            A         I    |
             I    |                           \ /        I    |
             I    |                            |         I    |
             I    |  HasSUPAPolicyStatements   |         I    |
             I    +---------------+------------+         I    |
             I                    ^                      I    |
             I                    |                      I    |
             I                    |                      I    |
        +----+----------+   +-----+-------------------+  I    |
        I               I   | HasSUPAPolicyStmtDetail |  I   / \
        I               I   +-------------------------+  I    A
        I               I                                I   \ / 0..1
    +---+---+  +--------+----------+           +---------+----+------+
    | Other |  | SUPAEncodedClause |           | SUPAPolicyComposite |
    |  Sub  |  +-------------------+           +---------------------+
    |Classes|
    +-------+

        Figure 8: SUPAPolicyStatements and SUPAPolicy Classes

   Note that the SUPAPAHasPolicyStmts aggregation was defined in
   Section 5.3.2.1.

Strassner                 Expires January 4, 2016            [Page 38]


Internet-Draft            SUPA Generic Policy Model          July 2015

   Note that in Figure 8:

      o SUPAPolicyStatement is a subclass of SUPAPolicy
      o SUPAPolicyStatements are aggregated by SUPAPolicyAtomic,
        which is a subclass of SUPAPolicy
      o SUPAPolicyComposite aggregates SUPAPolicyAtomic as well as
        SUPAPolicyComposite instance
      o A SUPAEncodedClause is a subclass of SUPAPolicyStatement,
        and may be used by either a SUPAECAPolicyRule or a
        SUPALogicStatement
      o SUPAPolicyStatement has two subclasses that are not shown in
        Figure 8: SUPABooleanClause and SUPALogicClause (they are
        discussed in Sections 6.5 and 7.4, respectively)
      o Both the HasSUPAPolicyStatements and the HasSUPAPolicies
        aggregations are implemented as association classes

   When defined in an information model, a SUPAPolicyStatement MUST be
   represented as a separate object that aggregates its constituent
   components. However, a data model MAY map this definition to a
   more efficient form (e.g., flattening the SUPAPolicyStatement and
   its aggregated object instances into a single object instance).

5.5.1. SUPAPolicyStatement Attributes

   This section defines the attributes of the SUPAPolicyStatement
   class. These attributes are inherited by all subclasses of the
   SUPAPolicyStatement class.

5.5.1.1. The Attribute "supaPolicyStmtAdminStatus"

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

   This attribute can be used to place this particular
   SUPAPolicyStatement into a specific administrative state, such as
   enabled, disabled, or in test. Note that since a SUPAPolicy (e.g.,
   a SUPAECAPolicyRule or a SUPALogicStatement) is made up of
   SUPAPolicyStatements, this enables all or part of a SUPAPolicy to
   be administratively controlled. Values include:

      0: Unknown (an error state)
      1: Enabled
      2: Disabled
      3: In Test (i.e., no operational traffic can be passed)

   Value 0 denotes an error that prevents this SUPAPolicyStatement
   from being used. Values 1 and 2 mean that this SUPAPolicyStatement
   is administratively enabled or disabled, respectively. A value of
   3 means that this SUPAPolicyStatement is in a special test mode and
   SHOULD NOT be used as part of an OAM&P policy.

Strassner                 Expires January 4, 2016            [Page 39]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.5.1.2. The Attribute "supaPolStmtExecStatus"

   This is an optional attribute, which is an enumerated non-negative
   integer. It defines whether this SUPAPolicyStatement is currently
   in use and, if so, what its execution status is.

   This attribute can be used to place this particular
   SUPAPolicyStatement into a specific execution state, such as
   enabled, disabled, or in test. Note that since a SUPAPolicy (e.g.,
   a SUPAECAPolicyRule or a SUPALogicStatement) is made up of
   SUPAPolicyStatements, this enables all or part of a SUPAPolicy to
   be administratively controlled. Values include:

      0: Unknown (an error state)
      1: Completed (i.e., successfully executed, but now idle)
      2: Working (i.e., in use and no errors reported)
      3: Not Working (i.e., in use, but errors have been reported)
      4: In Test (i.e., cannot be used as part of an OAM&P policy)
      5: Available (i.e., could be used, but currently isn't)
      6: Not Available (i.e., not available for use)

   Value 0 denotes an error that prevents this SUPAPolicyStatement
   from being used. Value 1 means that this SUPAPolicyStatement has
   successfully finished execution, and is now idle. Values 1-3 mean
   that this SUPAPolicyStatement is in use; in addition, this
   SUPAPolicyStatement is working correctly, not working correctly, or
   in a special test state, respectively. A test state signifies that
   it SHOULD NOT be used to evaluate OAM&P policies. Values 4-5 mean
   that this SUPAPolicyStatement is not currently in use; a value of 4
   means that it is available and could be used, while a value of 5
   means that it is unavailable.

5.5.1.3. The Attribute "supaPolStmtIsCNF"

   This is an optional Boolean attribute. If its value is true, then
   this SUPAPolicyStatement is in Conjunctive Normal Form (CNF). In
   Boolean logic, a formula that is in CNF is conceptually an AND of
   ORs. Otherwise, it is in Disjunctive Normal Form (i.e., an OR of
   ANDs).

5.5.2. SUPAPolicyStatement Subclasses

   As stated before, the primary purpose of SUPAPolicyStatement is to
   define a common type of Policy statement that can be used to
   represent policy content regardless of the type of SUPAPolicy that
   is being used (e.g., it is independent of the requirements of a
   SUPAECAPolicyRule or a SUPALogicStatement).




Strassner                 Expires January 4, 2016            [Page 40]


Internet-Draft            SUPA Generic Policy Model          July 2015


   The GPIM currently defines one subclass of SUPAPolicyStatement,
   called a SUPAEncodedClause, which can be used by both
   SUPAECAPolicyRules as well as SUPALogicStatements. Note that
   subclasses dedicated to the specific use of a SUPAECAPolicyRule
   and a SUPALogicStatement are defined in Sections 6.5 and 7.4,
   respectively.

   There are three principal subclasses of SUPAPolicyStatement:

      o SUPAEncodedClause, which is a mechanism to directly encode the
        content of the SUPAPolicyStatement into a set of attributes;
        this is described in more detai lin Section 5.5.2.1.
      o SUPABooleanClause, which defines a SUPAPolicyStatement as a
        set of one or more clauses; multiple clauses may be combined
        with Boolean AND and OR operators. This defines a SUPAPolicy
        as a completely reusable set of SUPAPolicy objects that are
        structured in an ECA form, and is described in more detail in
        Section 6.5.
      o SUPALogicClause, which defines a SUPAPolicyStatement as either
        a fact or a clause; both are expressed in first-order logic.
        This defines a SUPAPolicy as a completely reusable set of
        SUPAPolicy objects that are structured in FOL, and is
        described in more detail in Section 7.4.

   A SUPAPolicy MAY be constructed using any combination of the above
   three subclasses.

   Both SUPAECAPolicyRules (see Section 6) and SUPALogicStatements
   (see section 7) MUST use SUPAPolicyStatements to define their
   content. This enables the content of these different types of
   Policies to be represented in a common manner.

   Both SUPAECAPolicyRules and SUPALogicStatements MAY use a
   SUPAEncodedClause to define their content.

   SUPAECAPolicyRules SHOULD also use a SUPABooleanClause to define
   its content, while SUPALogicStatements SHOULD also use a
   SUPALogicClause to define its content.

5.5.2.1. The Concrete Class "SUPAEncodedClause"

   This is a mandatory concrete class that specializes (i.e., is a
   subclass of) a SUPAPolicyStatement. It defines a generalized
   extension mechanism for representing SUPAPolicyStatements that
   have not been modeled with other SUPAPolicy objects. Rather, the
   Policy Clause is directly encoded into the attributes of the
   SUPAEncodedClause. Note that other subclasses of
   SUPAPolicyStatement use SUPAPolicy objects to define their
   content.


Strassner                 Expires January 4, 2016            [Page 41]


Internet-Draft            SUPA Generic Policy Model          July 2015


   This class provides the developer a tradeoff of efficiency vs.
   reusability. SUPAEncodedClause was abstracted from DEN-ng [2],
   and a version of this class is in the process of being added to
   the policy framework defined in the TM Forum ZOOM model [5].

   This class uses two of its attributes (supaPolicyClauseContent and
   supaPolicyClauseFormat) for defining the content and format of a
   vendor-specific policy statement. This allows direct encoding of
   the policy statement, without having the "overhead" of using other
   objects. However, note that while this method is efficient, it
   does not reuse other SUPAPolicy objects. Rather, it can be thought
   of as a direct encoding of the policy statement. SUPAEncodedClause
   was abstracted from DEN-ng [2].

5.5.2.1.1. SUPAEncodedClause Attributes

   This section defines the attributes of the SUPAEncodedClause class.

5.5.2.1.1.1. The Attribute "supaClauseContent"

   This is a mandatory string attribute, and defines the content of
   this encoded clause of this clause. It works with another attribute
   of the SUPAEncodedClause class, called supaClauseFormat, 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 the encoded clause for the object instance of this class.
   This is based on the DEN-ng class design [2].

5.5.2.1.1.2. The Attribute "supaClauseFormat"

   This is a mandatory string attribute, and defines the format of
   this encoded clause. It works with another attribute of the
   SUPAEncodedClause class, called supaClauseContent, which
   defines the content (i.e., the value) 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 is based on the DEN-ng class
   design [2].

5.5.2.1.1.3. The Attribute "supaClauseResponse"

   This is an optional Boolean attribute that emulates a Boolean
   response of this clause, so that it may be combined with other
   subclasses of the SUPAPolicyStatement that provide a status as to
   their correctness and/or evaluation state.






Strassner                 Expires January 4, 2016            [Page 42]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.5.3. SUPAPolicyStatement Relationships

   This section defines the relationships of the SUPAPolicyStatement
   class.

5.5.3.1. The Aggregation "SUPAPolicyTermsInStmt"

   This is a mandatory aggregation that defines the set of
   SUPAPolicyTerms that are aggregated by this instance of this
   SUPAPolicyStatement. This enables a SUPAPolicyStatement to be
   constructed from a {variable, operator, value} 3-tuple. The
   multiplicity of this relationship is defined as 0..n on the
   aggregate (SUPAPolicyStatement) side, and 0..n on the part
   (SUPAPolicyTerm) side. This means that this relationship is
   optional, but if it is instantiated, then a given
   SUPAPolicyStatement may contain zero or more SUPAPolicyTerms, and
   a given SUPAPolicyTerm may be contained in zero or more
   SUPAPolicyStatements. This enables SUPAPolicyTerms to be stored
   in a PolicyRepository before they are bound to one or more
   SUPAPolicyStatements (and vice-versa). The semantics of this
   aggregation are implemented using the SUPAPolicyTermsInStmtDetail
   association class.

5.5.3.2. The Association Class "SUPAPolicyTermsInStmtDetail"

   This is a mandatory abstract association class that defines the
   semantics of the SUPAPolicyTermsInStmt aggregation. This enables
   the attributes and relationships of the SUPAPolicyTermsInStmt
   class to be used to constrain which SUPAPolicyStatement objects
   can aggregate which SUPAPolicyTerm objects.

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

5.5.3.2.1 SUPAPolicyStmtDetail Attributes

   No attributes are currently defined for the SUPAPolicyStmtDetail
   association class.


5.6. The Abstract Class "SUPAPolicySubject"

   This is an optional class that defines the set of managed entities
   that authored, or are otherwise responsible for, this
   SUPAPolicyStatement. Note that a SUPAPolicySubject does NOT
   evaluate or execute SUPAPolicies. Its primary use is for
   auditability.





Strassner                 Expires January 4, 2016            [Page 43]


Internet-Draft            SUPA Generic Policy Model          July 2015


   A SUPAPolicySubject SHOULD be mapped to a role (e.g., using the
   role-object pattern, as DEN-ng does). 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 Metadata.

   SUPAPolicySubject was abstracted from DEN-ng [2], and a version of
   this class is in the process of being added to the policy framework
   defined in the TM Forum ZOOM model [5]. A class diagram is shown in
   Figure 9.


    +------------------------+
    | HasSUPAPolicyTgtDetail |
    +-----------+------------+
                ^
                |            0..n +------------+
                |                \|            |
   +------------+-----------------+            |
   |    SUPAPolicyTargets        /|            |
   |                              | SUPAPolicy |
   |                         0..n |            |
   |    SUPAPolicySubjects       \|            |
   | +------------+---------------+            |
   | |            ^              /|            |
   | |            |               +------------+
   | |            |                     / \
   | | +----------+--------------+       I
   | | | HasSUPAPolicySubjDetail |       I
   | | +-------------------------+       I
   | |                                   I
   | |              +--------------------+------+---------------+
   | |              I                           I               I
   | |              I                           I               I
   | |              I                           I               I
   | | 0..1 +-------+---------+   0..1 +--------+-------+    (other
   | |   / \|                 |     / \|                |  SUPAPolicy
   | +--- A +SUPAPolicySubject|  +-- A +SUPAPolicyTarget|  subclasses)
   |     \ /|                 |  |  \ /|                |
   |        +-----------------+  |     +----------------+
   |                             |
   +-----------------------------+

          Figure 9.  SUPAPolicySubject and SUPAPolicyTarget








Strassner                 Expires January 4, 2016            [Page 44]


Internet-Draft            SUPA Generic Policy Model          July 2015

   In Figure 9:

      o SUPAPolicySubject and SUPAPolicyTarget are both subclasses
        of SUPAPolicy
      o Both the SUPAPolicyTargets amd the SUPAPolicySubjects
        aggregations are implemented as association classes
      o The multiplicity of both of the above aggregations are 0..1
        on the aggregate (SUPAPolicySubject or SUPAPolicyTarget) side
        and 0..n on the target (i.e., SUPAPolicy) side, respectively.
        This means that both aggregations are optional. If either is
        instantiated, then a SUPAPolicySubject or a SUPAPolicyTarget
        MAY contain zero or more SUPAPolicy object instances

   This model assumes that appropriate SUPAPolicySubject and
   SUPAPolicyTarget objects are added as subclasses of SUPAPolicy. If
   this is not the case, then the part side of both aggregations MUST
   be changed to where those objects are identified.

5.6.1. SUPAPolicySubject Attributes

   This section define the attributes of the SUPAPolicySubject class.

5.6.1.1. The Attribute "supaPolicySubjectIsAuthenticated"

   This is an optional Boolean attribute. If the value of this
   attribute is true, then this SUPAPolicySubject has been
   authenticated and can be used to verify the authorship of a
   SUPAPolicy.

5.6.2. SUPAPolicySubject Relationships

   This section defines the relationships of the SUPAPolicySubject
   class.

5.6.2.1. The Relationship "SUPAPolicySubjects"

   This is an optional association that defines the set of
   SUPAPolicySubjects that are associated with this particular
   SUPAPolicy object. The multiplicity of this relationship is
   defined as 0..1 on the SUPAPolicySubject side, and 0..n on the
   SUPAPolicy side. This means that this relationship is optional,
   but if it is implemented, then this particular SUPAPolicy object
   was authored by this set of SUPAPolicySubjects. The semantics of
   this association are implemented using the SUPAPolicySubjectDetail
   association class.







Strassner                 Expires January 4, 2016            [Page 45]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.6.2.2. The Association Class "SUPAPolicySubjectDetail"

   This is an optional concrete association class that defines the
   semantics of the SUPAPolicySubjects association. This enables the
   attributes and relationships of the SUPAPolicySubjectDetail class
   to be used to constrain which SUPAPolicySubject objects can be
   used to author this particular SUPAPolicy object instance.

5.6.2.2.1. SUPAPolicySubjectDetail Attributes

   Currently, one attribute is defined for the
   SUPAPolicySubjectDetail association class.

5.6.2.2.1.1. The Attribute "supaPolicySubjectIsVerified"

   This is an optional Boolean attribute. If the value of this
   attribute is true, then this SUPAPolicySubject has been verified
   to be the author of this particular SUPAPolicy object instance.


5.7. The Abstract Class "SUPAPolicyTarget"

   SUPAPolicyTarget was abstracted from DEN-ng [2], and a version of
   this class is in the process of being added to the policy framework
   defined in the TM Forum ZOOM model [5]. Figure 9 shows a class
   diagram of the SUPAPolicyTarget.

   A PolicyTarget is a set of managed entities that a SUPAPolicy is
   applied to. This is determined by two conditions.

   First, the set of managed entities 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 in a state that
   enables SUPAPolicies to be applied to it to change its state;
   hence, a negotiation process may need to occur to enable the
   SUPAPolicyTarget to signal when it is willing to have
   SUPAPolicies applied to it.

   Second, a SUPAPolicyTarget must be able to either process (either
   directly or with the aid of a proxy) SUPAPolicies or receive the
   results of a processed SUPAPolicy and apply those results to
   itself. If a proposed SUPAPolicyTarget meets both of these
   conditions, it SHOULD set its supaPolicyTargetEnabled Boolean
   attribute to a value of TRUE.

   A SUPAPolicyTarget SHOULD be mapped to a role (e.g., using the
   role-object pattern). Note that Role is a type of Metadata.




Strassner                 Expires January 4, 2016            [Page 46]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.7.1. SUPAPolicyTarget Attributes

   There are currently no attributes defined for the
   SUPAPolicyTarget class.

5.7.2. SUPAPolicyTarget Relationships

   This section defines the relationships of the SUPAPolicyTarget
   class.

5.7.2.1. The Relationship "SUPAPolicyTargets"

   This is an optional aggregation that defines the set of
   SUPAPolicyTargets that are contained in the instance of this
   particular SUPAPolicy object. This defines the set of entities that
   will be operated on by this particular SUPAPolicy object. The
   multiplicity of this relationship is defined as 0..1 on the
   aggregate (SUPAPolicy) side, and 0..n on the part
   (SUPAPolicyTarget) side. This means that this relationship is
   optional, but if it is implemented, then this particular SUPAPolicy
   object will operate on this set of SUPAPolicyTargets. The semantics
   of this aggregation are implemented using the
   HasSUPAPolicyTgtDetail association class.

5.7.2.2. The Association Class "SUPAPolicyTargetDetail"

   This is an optional concrete association class that defines the
   semantics of the SUPAPolicyTargets aggregation. This enables the
   attributes and relationships of the SUPAPolicyTargetDetail class
   to be used to constrain which SUPAPolicyTarget objects can be
   operated on by this particular SUPAPolicy object instance.

5.7.2.2.1. SUPAPolicyTargetDetail Attributes

   Currently, one attribute is defined for the SUPAPolicyTargetDetail
   association class

5.7.2.2.1.1. The Attribute "supaPolicyTargetEnabled"

   This is an optional Boolean attribute. If its value is TRUE, then
   this indicates that this SUPAPolicyTarget is currently able to
   have SUPAPolicies applied to it. Otherwise, this SUPAPolicyTarget
   is not able to have SUPAPolicies applied to it.








Strassner                 Expires January 4, 2016            [Page 47]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.8. The Abstract Class "SUPAPolicyTerm"

   This is a mandatory abstract class that is the parent of SUPAPolicy
   objects that can be used to define a standard way to test or set
   the value of a variable. It does this by defining a 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,
   respectively). For example, a generic test of the value of a
   variable is expressed as {variable, operator, value}.
   SUPAPolicyTerm was abstracted from DEN-ng [2].

   SUPAPolicyTerm is defined as an abstract class for two reasons:

      1. This enables a single aggregation (SUPAPolicyTermsInStmt; see
         section 5.8.2.1) to be used to specify which object instances
         of which SUPAPolicyTerm subclasses are contained by a
         particular SUPAPolicyStatement object instance. Otherwise, a
         set of three aggregations would be required.

      2. This enables a single class (SUPAPolicyTermsInStmtDetail; see
         section 5.8.2.2) to be used as a superclass to define which
         one of its subclasses participates in this relationship. The
         advantage of this design is that as more SUPAPolicyTerm
         subclasses are added in the future, the SUPAPolicyStatement
         object is not affected.

   This design emphasizes flexibility and genericity of the model.
   Specifically, this means that the concept of creating a
   SUPAPolicyStatement can take a generic form, consisting of the
   tuple {PolicyVariable, PolicyOperator, PolicyValue}. Note that this
   is only one option for constructing SUPAPolicyStatements, and is
   not mandatory; hence, the multiplicity of the SUPAPolicyTermsInStmt
   aggregation (see Section 5.8.2.) is 0..n - 0..n.

   This design is in marked contrast to most existing designs. For
   example, [RFC3060], [RFC3460], and [4] do not define an ECA Policy
   Rule; rather, they are limited to a Policy Rule that only has a
   condition clause and an action clause. This means that there is no
   mechanism for the system to trigger when a Policy Rule should be
   evaluated (because there is no event clause). This makes it very
   difficult to simulate what will happen when a policy rule is
   executed. In addition, [RFC3060], [RFC3460], and [4] do not define
   any type of logic statement (or, for that matter, any other type
   of Policy Rule).






Strassner                 Expires January 4, 2016            [Page 48]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.8.1. SUPAPolicyTerm Attributes

   Currently, SUPAPolicyTerm defines a single attributes, as described
   in the following subsection. Constraints on the subclasses of
   SUPAPolicyTerm are applied to individual classes as attributes, or
   through the SUPAPolicyTermsInStmtDetail association class (see
   section 5.8.2.2).

5.8.1.1 The Attribute "supaTermIsNegated"

   This is an optional Boolean attribute. If the value of this
   attribute is true, then this particular SUPAPolicyTerm subclass
   is negated; otherwise, it is not. This is based on the DEN-ng
   class design [2].


5.8.2. SUPAPolicyTerm Relationships

   Currently, SUPAPolicyTerm participates in a single relationship,
   as described in the following subsection.

5.8.2.1. The Aggregation "SUPAPolicyTermsInStmt"

   This is a mandatory aggregation that defines the set of
   SUPAPolicyTerms that are contained in this SUPAPolicyStatement.
   The multiplicity of this relationship is defined as 0..n on the
   aggregate (SUPAPolicyStatement) side, and 0..n on the part
   (SUPAPolicyTerm) side. This means that a SUPAPolicyStatement does
   not have to contain a SUPAPolicyTerm; this is typically true for
   SUPALogicStatement. However, if a SUPAPolicyStatement
   does require one or more SUPAPolicyTerms, then those may be
   defined using this aggregation. The semantics of this aggregation
   are implemented using the SUPAPolicyTermsInStmtDetail association
   class.

5.8.2.2. The Association Class "SUPAPolicyTermsInStmtDetail"

   This is a mandatory abstract association class that defines the
   semantics of the SUPAPolicyTermsInStmt aggregation. This enables
   the attributes and relationships of the SUPAPolicyTermsInStmtDetail
   class to be used to constrain which SUPAPolicyTerm objects can be
   aggregated by this particular SUPAPolicyStatement object instance.









Strassner                 Expires January 4, 2016            [Page 49]


Internet-Draft            SUPA Generic Policy Model          July 2015


   The preferred design is to keep this association class abstract,
   and create three subclasses from it that constrain the set of
   SUPAPolicyVariables, SUPAPolicyOperators, and SUPAPolicyValues
   that are used with this particular SUPAPolicyStatement. This
   provides a direct and simple mapping to optimized data models.
   Alternatively, appropriate attributes could be added to this
   association class to define the constraint, but such attributes
   would also have to take into account the type of PolicyTerm
   subclass that is being constrained.

5.8.2.2.1. SUPAPolicyTermsInStmtDetail Attributes

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

5.8.2.2.1.1. The Attribute "supaPolTermOCLConstraint"

   This is an optional string attribute that specifies a constraint
   to be applied. The constraint is defined in OCL 2.0. It is
   independent of the type of SUPAPolicyTerm that it applies to.


5.8.3. SUPAPolicyTerm Subclasses

   The following three subsections define three subclasses of the
   SUPAPolicyTerm class.

5.8.3.1. The Concrete Class "SUPAPolicyVariable"

   This is a mandatory concrete class that defines information that
   forms a part of a SUPAPOlicyStatement. It specifies a concept or
   attribute that should be compared to a value, as specifed in this
   SUPAPolicyStatement. If it is used in a SUPAECAPolicyRule, then
   its value MAY be able to be changed at any time. However, if it
   is used in a SUPALogicStatement, then it is typically bound to an
   expression, and keeps a single value during its entire lifetime.
   SUPAPolicyVariable was abstracted from DEN-ng [2].

   The value of a SUPAPolicyVariable is typically compared to the
   value of a SUPAPolicyValue using the type of operator defined in
   a SUPAPolicyOperator.

   SUPAPolicyVariables are used to abstract the representation of a
   SUPAPolicyRule from its implementation. Therefore, the design of
   SUPAPolicyVariables depends on two important factors.






Strassner                 Expires January 4, 2016            [Page 50]


Internet-Draft            SUPA Generic Policy Model          July 2015


   First, 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.
   Thus, any SUPAPolicyVariable can have a set of constraints
   associated with it that restrict the value, data type, and other
   semantics of the SUPAPolicyVariable when used in a particular
   SUPAPolicyStatement. Second, there is a high likelihood that
   specific applications will need to use their own variables that
   have specific meaning to a particular application.

   In general, there are two ways to apply constraints to an object
   instance of a SUPAPolicyVariable:

      o use a specific subclass of PolicyVariable, which has these
        constraints already applied to the attribute to be used
      o define constraints in the supaPolTermConstraints attribute
        of the SUPAPolicyTermsInStmtDetail association class (see
        Section 5.8.2.2.2.1.)

   The former approach was used in [RFC3460]. The problem with this
   approach is that it requires two additional subclasses (called
   PolicyImplicitVariable and PolicyExplicitVariable) with two
   different semantics, as well as three different associations. It
   also leads to class explosion. This draft keeps the idea of the
   class hierarchy for backwards compatibility, but streamlines the
   implementation.

   The latter approach is recommended, due to the use of established
   software patterns that can be used to populate the attribute(s)
   of the SUPAPolicyTermsInStmtDetail association class, or any
   subclass that is defined to refine its semantics.

5.8.3.1.1. Problems with the RFC3460 Version of PolicyVariable

   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
   SUPAPolicyVariable definition.

   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.


Strassner                 Expires January 4, 2016            [Page 51]


Internet-Draft            SUPA Generic Policy Model          July 2015


   Fourth, 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 a generic SUPAConstraint object.

   Fifth, [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)

   Finally, 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.

5.8.3.1.2. SUPAPolicyVariable Attributes

   Currently, SUPAPolicyVariable defines three generic attributes,
   as described below.

5.8.3.1.2.1. The Attribute "supaAllowedValueTypes[0..n]"

   This is an optional array of string attributes. Each attribute
   specifies a constraint to be applied using OCL 2.0. This provides
   a more rigorous and flexible treatment of constraints than is
   possible in [RFC3460].

5.8.3.1.2.2. The Attribute "supaPolVarContent"

   This is a string attribute that contains the value of the
   SUPAPolicyVariable object instance. Its data type is defined by
   the supaPolVarType class attribute.

5.8.3.1.2.3. The Attribute "supaPolVarType"

   This is a string attribute that contains the data type of the
   SUPAPolicyVariable object instance. Its value is defined by
   the supaPolVarContent class attribute.





Strassner                 Expires January 4, 2016            [Page 52]


Internet-Draft            SUPA Generic Policy Model          July 2015

5.8.3.1.3. SUPAPolicyVariable Subclasses

   A set of SUPAPolicyVariable subclasses will be defined in the
   next version of this document. These are included for backwards
   compatibility with existing designs based on [RFC3460]. This is
   a more complex approach, and is not recommended.

5.8.3.2. The Concrete Class "SUPAPolicyOperator"

   This is a mandatory concrete class for modeling different types of
   operators that are used in a SUPAPolicyStatement.

   A SUPAPolicyOperator is a mandatory concrete class that defines
   the type of operator to be applied to a SUPAPolicyStatement that
   is created from a set of SUPAPolicyTerms. This class is based on
   a similar class defined in [2].

   The restriction of the type of operator used in a
   SUPAPolicyStatement restricts the semantics that can be expressed
   in that SUPAPolicyStatement.

5.8.3.2.1. Problems with the RFC3460 Version

   Note that this class is NOT present in either RFC[3060] or
   [RFC3460]; instead, both hardwire the operator to a "MATCH"
   function. Quoting from [RFC3460]:

      "A simple condition models an elementary Boolean expression of
       the form 'variable MATCHes value". However, the formal
       notation of the SimplePolicyCondition, together with its
       associations, models only a pair, (<variable>, <value>). The
       'MATCH' operator is not directly modeled -- it is implied.
       Furthermore, this implied 'MATCH' operator carries overloaded
       semantics [sic]."

   In stark contrast to this, SUPA defines a SUPAPolicyOperator as a
   formal subclass of SUPAPolicyTerm. A single attribute, called
   supaPolOpType, carries the operator to be applied to the
   SUPAECAPolicyRule. This has the important advantage of enabling
   ECA policy rules of varying functionality to be created by a
   human or a machine.

5.8.3.2.2. SUPAPolicyOperator Attributes

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






Strassner                 Expires January 4, 2016            [Page 53]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.8.3.2.2.1. The Attribute "supaPolOpType"

   This is a mandatory non-negative enumerated integer that specifies
   the various types of operators that are allowed to be used in this
   particular SUPAPolicyStatement. Values include:

     0:  Unknown
     1:  Match
     2:  Greater than
     3:  Greater than or equal to
     4:  Less than
     5:  Less than or equal to
     6:  Equal to
     7:  Not equal to
     8:  IN
     9:  NOT IN
    10:  SET
    11:  CLEAR

   Note that 0 is an unacceptable value. Its purpose is to support
   dynamically building a SUPAPolicyStatement by enabling the
   application to set the value of this attribute to a standard
   default value if the real value is not yet known.


5.8.3.3. The Concrete Class "SUPAPolicyValue"

   The SUPAPolicyValue class is a mandatory concrete class for
   modeling different types of values and constants that occur in a
   PolicyStatement. SUPAPolicyValue was abstracted from DEN-ng [2].

   The value of a SUPAPolicyVariable is typically compared to the
   value of a SUPAPolicyValue using the type of operator defined in a
   SUPAPolicyOperator.

   SUPAPolicyValues are used to abstract the representation of a
   SUPAPolicyRule from its implementation. Therefore, the design of
   SUPAPolicyValues depends on two important factors. First, just as
   with SUPAPolicyVariables (see Section 5.8.3.1), some types of
   SUPAPolicyValues are 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 use their own variables
   that have specific meaning to a particular application.

   In general, there are two ways to apply constraints to an object
   instance of a SUPAPolicyValue:





Strassner                 Expires January 4, 2016            [Page 54]


Internet-Draft            SUPA Generic Policy Model          July 2015


      o use a specific subclass of PolicyValue, which has these
        constraints already applied to the attribute to be used
      o define constraints in the supaPolTermConstraints attribute
        of the SUPAPolicyTermsInStmtDetail association class (see
        Section 5.8.2.2.2.1.)

   The former approach was used in [RFC3460]. The problem with this
   approach is that it generates a set of classes, each having a
   single data type, to represent a primitive type. Hence, this
   approach may lead to class explosion. This draft keeps the idea
   of the class hierarchy for backwards compatibility, but
   streamlines the implementation.

   The latter approach is recommended, due to the use of established
   software patterns that can be used to populate the attribute(s)
   of the SUPAPolicyTermsInStmtDetail association class, or any
   subclass that is defined to refine its semantics.

5.8.3.3.1. Problems with the RFC3460 Version of PolicyValue

   First, [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.

   Second, 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.

   Third, in [RFC3460], there is no generic facility for defining
   constraints for a PolicyValue.

   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)

5.8.3.3.2. SUPAPolicyValue Attributes

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





Strassner                 Expires January 4, 2016            [Page 55]


Internet-Draft            SUPA Generic Policy Model          July 2015


5.8.3.3.2.1. The Attribute "supaPolValContent"

   This is a string attribute that contains the value of the
   SUPAPolicyValue object instance. Its data type is defined by
   the supaPolValType class attribute.

5.8.3.3.2.2. The Attribute "supaPolValType"

   This is a string attribute that contains the data type of the
   SUPAPolicyValue object instance. Its value is defined by the
   supaPolValContent class attribute.

5.8.3.3.3. SUPAPolicyValue Subclasses

   A set of SUPAPolicyValue subclasses will be defined in the
   next version of this document. These are included for backwards
   compatibility with existing designs based on [RFC3460]. This is
   a more complex approach, and is not recommended.


5.9. The Abstract Class "SUPAPolicyMetadata"

   THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT.

   SUPAPolicyMetadata was abstracted from DEN-ng [2]. A more complete
   representation of metadata, as defined in [2], is in the process
   of being added to the policy framework defined in the TM Forum
   ZOOM model [5].

5.9.1. SUPAPolicyMetadata Attributes

   THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT.

5.9.2. SUPAPolicyMetadata Relationships

   THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT.















Strassner                 Expires January 4, 2016            [Page 56]


Internet-Draft            SUPA Generic Policy Model          July 2015



6. SUPA ECAPolicyRule Information Model

   This section defines the classes, attributes, and relationships
   of the SUPA ECAPolicyRule Information Model (EPRIM).

6.1. Overview

   Conceptually, the EPRIM is a set of subclasses that specialize the
   concepts defined in the GPIM for representing the components of a
   Policy that uses ECA semantics. This is shown in Figure 10.


   (Class of another model that SUPA is integrating into)
       |
       +---SUPAPolicy (see Section 5.2)
       |     |
       |     +---SUPAPolicyAtomic (see Section 5.3)
       |     |     |
       |     |     +---SUPAECAPolicyRule (see Section 6.4)
       |     |     |
       |     |     +---SUPAECAComponent (see Section 6.6)
       |     |           |
       |     |           +---SUPAEvent (see Section 6.6.3.1)
       |     |           |
       |     |           +---SUPACondition (see Section 6.6.3.2)
       |     |           |
       |     |           +---SUPAAction (see Section 6.6.3.3)
       |     |
       |     +---SUPAPolicyComposite (see Section 5.4)
       |     |
       |     +---SUPAPolicyStatement (see Sections 5.5 and 6.5)
       |     |     |
       |     |     +---SUPAEncodedClause (see Section 5.5.2.1)
       |     |     |
       |     |     +---SUPABooleanClause (see Section 6.5.2)
       |     |
       |     +---SUPAPolicySubject (see Section 5.6)
       |     |
       |     +---SUPAPolicyTarget (see Section 5.7)
       |     |
       |     +---SUPAPolicyTerm (see Section 5.8)
       |     |
       |     +---SUPAPolicyMetadata (see Section 5.9)
      ...

          Figure 10: The EPRIM Refining the GPIM




Strassner                 Expires January 4, 2016            [Page 57]


Internet-Draft            SUPA Generic Policy Model          July 2015

   Specifically, the EPRIM specializes the SUPAPolicyAtomic class to
   create a SUPAECAPolicyRule; it also specializes the SUPAPolicy
   class to create a SUPAECAComponent, and the SUPAPolicyStatement to
   create a SUPABooleanClause. The SUPAECAPolicyRule uses the rest of
   the GPIM infrastructure to define a complete Policy model
   according to ECA semantics.

   The overall strategy for refining the GPIM is as follows:

      o SUPAECAPolicyRule is defined as a subclass of the GPIM
        SUPAPolicyAtomic class
      o A SUPAECAPolicyRule has event, condition, and action clauses;
        each of these are created by either a SUPABooleanClause or a
        SUPAEncodedClause (subclasses of SUPAPolicyStatement)
      o Both a SUPABooleanClause and a SUPAEncodedClause inherit the
        HasSUPAECAComponents aggregation, so both of these types of
        clauses can use SUPAECAComponents in their construction
        o A SUPAECAComponent defines SUPAEvent, SUPACondition, and
          SUPAAction objects that can optionally be used to create the
          event, condition, and action clauses of a SUPAECAPolicyRule
      o Both a SUPABooleanClause and a SUPAEncodedClause inherit the
        SUPAPolicyTermsInStmt aggregation, so both of these types of
        clauses can use SUPAPolicyTerms in their construction
      o An optional set of GPIM SUPAPolicySubjects can be defined to
        represent the authoring of a SUPAECAPolicyRule
      o An optional set of GPIM SUPAPolicyTargets can be defined to
        represent the set of managed entities that will be affected
        by this SUPAECAPolicyRule
      o An optional set of SUPAPolicyMetadata can be defined for any
        of the objects that make up a SUPAECAPolicyRule and/or a
        SUPAECAComponent


6.2. Constructing a SUPAECAPolicyRule

   There are several different ways to construct a SUPAECAPolicyRule.
   The simplest approach is as follows:

      o Define three types of SUPABooleanClauses (see Section 6.7),
        one each for the event, condition, and action clauses that
        make up a SUPAECAPolicyRule (see Section 6.4)
      o Define a set of SUPAEvent, SUPACondition, and SUPAAction
        objects (see Section 6.5.1, 6.5.2, and 6.5.4, respectively),
        and associate each with the SUPABooleanClause that represents
        the event, condition, and action clauses, respectively, of the
        SUPAECAPolicyRule
      o Define a SUPAECAPolicyRule, which is a subclass of the GPIM
        SUPAPolicyAtomic class (see Section 5.3)




Strassner                 Expires January 4, 2016            [Page 58]


Internet-Draft            SUPA Generic Policy Model          July 2015


      o Aggregate the three SUPABooleanClauses into the
        SUPAECAPolicyRule
      o Optionally, define a set of SUPAPolicySubjects and
        SUPAPolicyTargets, and aggregate them into the
        SUPAECAPolicyRule
      o Optionally, define SUPAPolicyMetadata for any of the above
        objects, and aggregate them to the SUPAPolicy objects that
        the SUPAPolicyMetadata applies to


6.3. Working With SUPAECAPolicyRules

   A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that
   MUST have three clauses, defined as follows:

      o The event clause defines a Boolean expression that, if
        TRUE, triggers the evaluation of its condition clause (if the
        event clause is not TRUE, then no further action for this
        policy rule takes place).
      o The condition clause defines a Boolean expression that, if
        TRUE, enables the actions in the action clause to be executed
        (if the condition clause is not TRUE, then no further action
        for this policy rule takes place).
      o The action clause is a set of actions, whose
        execution MAY be controlled by the SUPAMmetadata of the
        policy rule.

   Note that in theory, the condition clause of an ECA policy rule
   could also include multiple clauses (like, for example, a switch
   statement). Similarly, multiple action clauses (i.e., one for
   each distinct condition clause) could be included as well. This
   was done on a limited basis in DEN-ng. However, this complicates
   the overall design, so at this time, SUPA is not providing this
   facility.

   Each of the three clauses can be constructed from either a
   SUPAEncodedClause or a SUPABooleanClause. The advantage of using
   SUPAEncodedClauses is simplicity, as the content of the clause is
   encoded directly into the attributes of the SUPAEncodedClause. The
   advantage of using SUPABooleanClauses is reusability, since each
   term in each clause is potentially a reusable object.

   Since a SUPABooleanClause is a subclass of a SUPAPolicyStatement
   (see Section 5.5), it can aggregate SUPAPolicyTerm objects as well
   as SUPAECAComponent objects. Therefore, a SUPAECAPolicyRule can be
   built entirely from objects defined in the GPIM. As will be shown
   in Section 7.4, this is also true for SUPALogicStatements.




Strassner                 Expires January 4, 2016            [Page 59]


Internet-Draft            SUPA Generic Policy Model          July 2015

  The construction of a SUPAECAPolicyRule is shown in Figure 11, and
  is explained in Section 6.4.

       0..n +----------------------+
         / \|                      |
     +--- A +   SUPAPolicyAtomic   |        +-------------------+
     |   \ /|                      |        |     SUPAPolicy    |
     |      +---------+------------+        +----------+--------+
     |               / \                            / \
     |                I                              I
     |                I                              I
     |   +------------+------------+    +------------+------------+
     |   |    SUPAECAPolicyRule    |    |     SUPAECAComponent    |
     |   +-------------------------+    +------------+------------+
     |                                          1..n/ \
     |                                               |
     |                +-------------------------+    |
     |                |HasSUPAECAComponentDetail|    |
     |                +-------------+-----------+    |
     |                              ^                |
     |                              |                |
     |                              |                |
     +------------------------------+----------------+
                           HasSUPAECAComponents


                Figure 11.  SUPAECAPolicyRule Clauses

   NOTE: This is a simplified design, inspired from [2]. The
   HasSUPAECAComponents aggregation is implemented using the
   HasSUPAECAComponentDetail association class. This is an abstract
   class further described in Section 6.4.2. It has three concrete
   subclasses, one each that correspond to the three subclasses of
   SUPAECAComponent (i.e., SUPAEvent, SUPACondition, and SUPAAction),
   which are all concrete. This enables one aggregation to define a
   set of constraints between a SUPAPolicyStatement and the set of
   Events, Conditions, and/or Actions that it can contain.


6.4. The Concrete Class "SUPAECAPolicyRule"

   This is a concrete mandatory class. In keeping with the original
   DEN-ng model [1], this class is a PolicyContainer that contains
   PolicyEvents, PolicyConditions, PolicyActions, and optionally,
   PolicySubjects, PolicyTargets, and PolicyMetadata. As such, it
   does not have an inherent relationship with PolicySubject or
   PolicyTarget; these all represent the specific semantics for a
   particular SUPAPolicy. Hence, such semantics are defined in an
   instance of the SUPAPolicyComposite class that contains a
   SUPAECAPolicyRule, if they are required.


Strassner                 Expires January 4, 2016            [Page 60]


Internet-Draft            SUPA Generic Policy Model          July 2015

   An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an
   abstract class that represents a policy rule as a three-tuple,
   consisting of at least one event clause, one condition clause, and
   one action clause. Each clause MUST be defined by at least one
   SUPAPolicyStatement. Optionally, the SUPAECAPolicyRule MAY contain
   one or more SUPAPolicySubjects, one or more SUPAPolicyTargets, and
   one or more SUPAPolicyMetadata objects.

   There are two main ways that the event, condition, and action
   clauses of a SUPAECAPolicyRule can be populated:

      o Use a SUPAEncodedClause
      o Use a SUPABooleanClause using SUPAECAComponents and/or
        SUPAPolicyTerms

   Regardless of which approach is taken, the operation of a
   SUPAECAPolicyRule is identical:

      o the event clause specifies what triggers the evaluation
        of the SUPAECAPolicyRule
      o the condition clause specifies whether the condition clause
        has evaluated to TRUE or FALSE, and hence, whether the
        action clause should be executed or not
      o the action clause specifies the set of actions to be executed

   If there is more than one term, then these terms MUST be combined
   using any combination of logical AND, OR, and NOT operators to
   form a Boolean clause (i.e., a clause whose value is either TRUE
   or FALSE). For example, a valid event clause could be: "three
   events of type A AND NOT an event of type B".

   This behavior differentiates a SUPAECAPolicyRule from a
   SUPALogicStatement, which specifies the set of actions to perform,
   but not how to implement or execute them.

   The behavior of the event, condition, and action clauses MAY be
   specified using one or more SUPAMetadata objects that have been
   aggregated by the SUPAECAPolicyRule. Note that one or more
   SUPAMetadata objects may also be aggregated by any of the
   components of a SUPAECAPolicyRule.

   A SUPAECAPolicyRule MAY specify a set of SUPAPolicySubjects that
   have authored the SUPAECAPolicyRule. A SUPAECAPolicyRule MAY
   specify a set of SUPAPolicyTargets that define a set of managed
   objects that the actions of the SUPAECAPolicyRule MAY monitor
   and/or change their state.






Strassner                 Expires January 4, 2016            [Page 61]


Internet-Draft            SUPA Generic Policy Model          July 2015


   When defined in an information model, each of the event, condition,
   and action clauses MUST be represented as an aggregation between a
   SUPAECAPolicyRule (the aggregate) and a set of event, condition, or
   action objects (the components). However, a data model MAY map
   these definitions to a more efficient form (e.g., by flattening
   these three types of object instances, along with their respective
   aggregations, into a single object instance).

   The semantics of a SUPAECAPolicyRule may be conceptualized as
   follows:
      ON RECEIPT OF <policy-event-clause>
         IF <policy-condition-clause> EVALUATES TO TRUE
            THEN EXECUTE <policy-action-clause>
         END
      END

   In the above, a policy-event-clause, policy-condition-clause, and
   a policy-action-clause are each instances of either a
   SUPAEncodedClause or a SUPABooleanClause.

   SUPAECAPolicyRule was abstracted from DEN-ng [2], and a version
   of this class is in the process of being added to the policy
   framework defined in the TM Forum ZOOM model [5].

6.4.1. SUPAECAPolicyRule Attributes

   Currently, the SUPAECAPolicyRule defines three attributes, as
   described in the following subsections.

6.4.1.1. The Attribute "supaECAPolicyIsMandatory"

   This is an optional Boolean attribute. If the value of this
   attribute is true, then this SUPAECAPolicyRule MUST be executed
   (i.e., its Event and Condition clauses are irrelevant, and the
   Action(s) specified in the Action clause MUST be executed).
   These actions will use the inhertied supaPolicyExecStrategy
   attribute to govern which of the Actions in this SUPAECAPolicyRule
   will be executed or not.

6.4.1.2. The Attribute "supaECAPolicyPriority"

   This is a mandatory non-negative integer attribute that defines
   the priority of this particular SUPAECAPolicyRule. A larger value
   indicates a higher priority. A default value of 0 MAY be assigned.







Strassner                 Expires January 4, 2016            [Page 62]


Internet-Draft            SUPA Generic Policy Model          July 2015


6.4.2. SUPAECAPolicyRule Relationships

   Currently, the SUPAECAPolicyRule defines a single aggregation
   between it and SUPAECAComponent, as described below. Note that
   the remaining functionality that SUPAECAPolicyRule requires is
   provided by other relationships within the GPIM and EPRIM. For
   example, the aggregation SUPAHasPolicyStmts (see section 5.3.2.1)
   defines the set of SUPAPolicyStatements that MUST be aggregated
   by this particular SUPAPolicyAtomic object.

6.4.2.1. The Aggregation "SUPAECAPolicyRules"

   This is an optional aggregation that defines the set of SUPAEvents,
   SUPAConditions, and SUPAActions that are aggregated by this
   particular SUPAECAPolicyRule. The multiplicity of this aggregation
   is 0..1 on the aggregate (SUPAECAPolicyRule) side and 1..n on the
   part (SUPAECAComponent) side. This means that if this aggregation
   is defined, then at least one SUPAECAComponent must also be
   instantiated and aggregated by the SUPAECAPolicyRule. However, a
   SUPAECAComponent does not have to be instantiated when a
   SUPAECAComponent is instantiated; this enables SUPAECAComponent
   objects to be stored in a repository, for use as a library. The
   semantics of this aggregation are defined by the
   SUPAECADetail association class.

6.4.2.1.1. The Association Class "HasSUPAECAComponentDetail"

   This is an optional association class, and defines the semantics
   of the HasSUPAECAComponent aggregation. This enables the
   attributes and relationships of the SUPAPAHasPolicyStmtDetail
   class to be used to constrain which SUPAPolicyStatements objects
   can be aggregated by this particular SUPAPolicyAtomic object
   instance. Attributes will be added to this class at a later time.


6.4.3. SUPAECAPolicyRule Subclasses

   The composite pattern [3] is applied to the SUPAECAPolicyRule
   class, enabling it to be used as either a stand-alone policy rule
   or as a hierarchy of policy rules. This is shown in Figure 12.

   SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both
   inherit from SUPAECAPolicyRule. This means that they are both
   a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRules
   aggregation enables a particular SUPAECAPolicyRuleComposite
   object to aggregate both SUPAECAPolicyRuleComposite as well as
   SUPAECAPolicyRuleAtomic objects. In contrast, a
   SUPAECAPolicyRuleAtomic can NOT aggregate either a
   SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic.


Strassner                 Expires January 4, 2016            [Page 63]


Internet-Draft            SUPA Generic Policy Model          July 2015


                           1..n +-------------------+
                               \|                   |
               +--------------- + SUPAECAPolicyRule |
               |               /|                   |
               |                +--------+----------+
               |                        / \
               | HasSUPAECAPolicyRules   I
               |                         I
               |                         I
               |                         I
               |        +----------------+---------+
               |        I                          I
              / \       I                          I
               A        I                          I
         0..1 \ /       I                          I
       +-------+--------+---------+    +-----------+-----------+
       |SUPAECAPolicyRuleComposite|    |SUPAECAPolicyRuleAtomic|
       +--------------------------+    +-----------------------+

   Figure 12.  The Composite Pattern Applied to a SUPAECAPolicyRule


6.4.3.1. The Concrete Class "SUPAECAPolicyRuleAtomic"

   This is a mandatory concrete class. This class is a type of
   PolicyContainer. SUPAECAPolicyRuleAtomic was abstracted from
   DEN-ng [2], and a version of this class is in the process of
   being added to the policy framework defined in the TM Forum ZOOM
   model [5].

   A SUPAECAPolicyRuleAtomic class represents a SUPA ECA Policy Rule
   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.4.3.1.1. SUPAECAPolicyRuleAtomic Attributes

   No attributes are currently defined for the SUPAECAPolicyRule
   class.

6.4.3.1.2. SUPAECAPolicyRuleAtomic Relationships

   No relationships are currently defined for the SUPAECAPolicyRule
   class.





Strassner                 Expires January 4, 2016            [Page 64]


Internet-Draft            SUPA Generic Policy Model          July 2015


6.4.3.2. The Concrete Class "SUPAECAPolicyRuleComposite"

   This is a mandatory concrete class. This class is a type of
   PolicyContainer. SUPAECAPolicyRuleComposite was abstracted from
   DEN-ng [2], and a version of this class is in the process of
   being added to the policy framework defined in the TM Forum ZOOM
   model [5].

   A SUPAECAPolicyRuleComposite class represents a SUPA ECA Policy
   Rule as a hierarchy of Policy objects, where the hierarchy
   contains instances of a SUPAECAPolicyRuleAtomic and/or
   SUPAECAPolicyRuleComposite object. Each of the SUPA Policy
   objects, including the outermost SUPAECAPolicyRuleComposite
   object, are separately manageable. More importantly, the
   SUPAECAPolicyRuleComposite object can aggregate any
   SUPAECAPolicyRule subclass. Hence, it can be used to form
   hierarchies of SUPAECAPolicyRules as well as associate
   SUPAPolicySubjects and/or SUPAPolicyTargets to a given
   SUPAECAPolicyRule.

6.4.3.2.1. SUPAECAPolicyRuleAtomic Attributes

   Currently, the SUPAECAPolicyRule defines two attributes, as
   described in the following subsections.

6.4.3.2.1.1. The Attribute "supaECAEvalStrategy"

   This is a mandatory, non-zero, integer attribute that enumerates
   a set of allowable alternatives that define how the actions in a
   SUPAPolicyRuleComposite are evaluated. Values include:

      0:  undefined
      1:  execute all actions regardless of their execution status
      2:  execute all actions until one or more actions fail
      3:  execute only the highest priority action(s)

6.4.3.2.1.2. The Attribute "supaECAFailStrategy"

   This is a mandatory, non-zero, integer attribute that enumerates
   a set of allowable alternatives that define how actions that do
   not execute successfully should be handled. Values include:

      0:  undefined
      1:  rollback just the failed action
      2:  rollback all actions that have been executed in this
          SUPAECAPolicyRule
      3:  ignore failures and continue




Strassner                 Expires January 4, 2016            [Page 65]


Internet-Draft            SUPA Generic Policy Model          July 2015


6.4.3.2.2. SUPAECAPolicyRuleComposite Relationships

   Currently, a single aggregation is defined for the
   SUPAECAPolicyRuleComposite class, which is defined below.

6.4.3.2.2.1. The Aggregation "SUPAECAPolicyRules"

   This is a mandatory aggregation that defines the set of
   SUPAECAPolicyRule objects (i.e., instances of either the
   SUPAECAPolicyRuleAtomic or SUPAECAPolicyRuleComposite classes)
   that are contained in this particular SUPAECAPolicyRuleComposite
   object instance. The semantics of this aggregation are defined in
   the SUPAECAPolicyRuleDetail association class.

6.4.3.2.2.2. The Association Class "SUPAECAPolicyRuleDetail"

   This is a mandatory association class, and defines the semantics
   of the SUPAECAPolicyRules aggregation. This enables the
   attributes and relationships of the SUPAECAPolicyRuleDetail
   class to be used to constrain which SUPAECAPolicyRule objects
   can be aggregated by this particular SUPAPolicyComposite object
   instance. Attributes will be added to this class at a later time.


6.5. SUPAPolicyStatement Subclasses

   Section 5.5.2 defines a common subclass of SUPAPolicyStatement,
   called SUPAEncodedClause, which any SUPAPolicy (rule or predicate)
   can use. This section describes another specialization of the
   GPIM SUPAPolicyStatement class for use in constructing (only)
   SUPAECAPolicyRule objects.

   The SUPAPolicyStatement class, and its subclasses, are based on
   similar classes in [2].

6.5.1. Designing SUPAPolicyStatements Using SUPABooleanClauses

   A SUPABooleanClause specializes a SUPAPolicyClause, and defines a
   Boolean statement consisting of a standard structure in the form
   of a PolicyVariable, a PolicyOperator, and a PolicyValue. This
   design is based on the DEN-ng model [2]. For example, this enables
   the following Boolean clause to be defined:

      Foo >= Bar AND Baz







Strassner                 Expires January 4, 2016            [Page 66]


Internet-Draft            SUPA Generic Policy Model          July 2015


   where Foo is a PolicyVariable, >= is a PolicyOperator, and Bar is
   a PolicyValue. Note that in this approach, each of these three
   terms (i.e., the PolicyVariable, PolicyOperator, and PolicyValue)
   are subclasses of the SUPAPolicyTerm class, which is defined in
   Section 5.8). This enables the EPRIM, in conjunction with the
   GPIM, to be used as a reusable class library. This encourages
   interoperability, since each element of the clause is itself an
   object defined by SUPA.

   The addition of a negation in the above statement is provided by
   the supaTermIsNegated Boolean attribute in the SUPAPolicyTerm
   class. An entire clause is indicated as negated using the
   supaBoolIsNegated Boolean attribute in the SUPABooleanClause class.

   A PolicyStatement is in Conjunctive Normal Form (CNF) if it is a
   conjunction (i.e., a sequence of ANDed terms), where each term is a
   disjunction (i.e., a sequence of ORed terms). Every statement that
   consists of a combination of AND, OR, and NOT operators can be
   written in CNF.

   A PolicyStatement is in Disjunctive Normal Form (DNF) if it is a
   disjunction (i.e., a sequence of ORed terms), where each term is a
   conjunction (i.e., a sequence of ANDed terms). Every statement that
   consists of a combination of AND, OR, and NOT operators can be
   written in DNF.

   The supaBoolISCNF Boolean attribute of the SUPABooleanClause class
   is TRUE if this SUPABooleanClause is in CNF, and FALSE otherwise.

   The construction of more complex clauses, which consist of a set
   of simple clauses in conjunctive or disjunctive normal form (as
   shown in the above example), is provided by using the composite
   pattern [3] to construct two subclasses of SUPABooleanClause.
   These are called SUPABooleanClauseAtomic and
   SUPABooleanClauseComposite, and are defined in Sections 6.5.2.1 and
   6.5.2.2, respectively. This enables instances of either a
   SUPABooleanClauseAtomic and/or a SUPABooleanClauseComposite to be
   aggregated into a SUPABooleanClauseComposite object.


6.5.2. The Abstract Class"SUPABooleanClause"

   This is a mandatory abstract class that defines a clause as the
   following three-tuple:

         {PolicyVariable, PolicyOperator, PolicyValue}





Strassner                 Expires January 4, 2016            [Page 67]


Internet-Draft            SUPA Generic Policy Model          July 2015


   The composite pattern [3] is used in order to construct complex
   Boolean clauses from a set of SUPABooleanClause objects. This is
   why SUPABooleanClause is defined to be abstract - only instances
   of the SUPABooleanAtomic and/or SUPABooleanComposite classes can
   be used to construct a SUPABooleanClause.

   SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both
   inherit from SUPAECAPolicyRule. This means that they are both
   a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRules
   aggregation enables a particular SUPAECAPolicyRuleComposite
   object to aggregate both SUPAECAPolicyRuleComposite as well as
   SUPAECAPolicyRuleAtomic objects. In contrast, a
   SUPAECAPolicyRuleAtomic can NOT aggregate either a
   SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic.

   The advantage of a SUPABooleanClause is that it is formed entirely
   from SUPAPolicy objects. This enhances both reusability as well as
   interoperability. Since this involves compositing a number of
   objects, data model implementations MAY optimize a
   SUPABooleanClause according to their application-specific needs
   (e.g., by flattening the set of classes that make up a
   SUPABooleanClause object into a single object).

   Figure 13 below shows the composite pattern applied to the
   SUPABooleanClause class.

                           1..n +-------------------+
                               \|                   |
               +--------------- + SUPABooleanClause |
               |               /|                   |
               |                +--------+----------+
               |                        / \
               | HasSUPABooleanClauses   I
               |                         I
               |                         I
               |        +----------------+---------+
              / \       I                          I
               A        I                          I
         0..1 \ /       I                          I
       +-------+--------+---------+    +-----------+-----------+
       |SUPABooleanClauseComposite|    |SUPABooleanClauseAtomic|
       +--------------------------+    +-----------------------+

   Figure 13.  The Composite Pattern Applied to a SUPABooleanClause


6.5.2.1. SUPABooleanClause Attributes

   The following sections define attributes of a SUPABooleanClause.


Strassner                 Expires January 4, 2016            [Page 68]


Internet-Draft            SUPA Generic Policy Model          July 2015


6.5.2.1.1. The Attribute "supaBoolIsNegated"

   This is a mandatory Boolean attribute. If the value of this
   attribute is TRUE, then this SUPABooleanClause is negated.

6.5.2.1.2. The Attribute "supaPolStmtBindValue"

   This is an optional non-zero integer attribute, and defines the
   order in which terms bind to a clause. For example, the Boolean
   statement "((A AND B) OR (C AND NOT (D or E))) has the following
   binding order: terms A and B have a bind value of 1; term C has a
   binding value of 2, and terms D and E have a binding value of 3.


6.5.2.2. SUPABooleanClause Relationships

   The following subsections define the relationships of a
   SUPABooleanClause.

6.5.2.2.1. The Relationship "SUPABooleanClauses"

   This is a mandatory aggregation that defines the set of
   SUPABooleanClauses that are aggregated by this
   SUPABooleanClauseComposite. This will either form a complete
   SUPABooleanClause from multiple clauses (which can be made up of
   SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite object
   instances) or define another level in the SUPABooleanClause object
   hierarchy.

   The 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 defined by the SUPABooleanClauseDetail
   association class.

6.5.2.2.1.1. The Association Class "SUPABooleanClauseDetail"

   This is a mandatory association class that defines the semantics
   of the SUPABooleanClauses aggregation. This enables the
   attributes and relationships of the SUPABooleanClauseDetail
   class to be used to constrain which SUPABooleanClause objects
   can be aggregated by this particular SUPABooleanClauseComposite
   object instance. Attributes will be added to this class at a
   later time.


Strassner                 Expires January 4, 2016            [Page 69]


Internet-Draft            SUPA Generic Policy Model          July 2015


6.5.3. SUPABooleanClause Subclasses

   SUPABooleanClause defines two subclasses, as shown in Figure 13.
   They are both described in the following subsections.

6.5.3.1. The Abstract Class "SUPABooleanClauseAtomic"

   This is a mandatory concrete class that represents a
   SUPABooleanClause that can operate as a single, stand-alone,
   manageable object. Put another way, a SUPABooleanClauseAtomic
   object can NOT be modeled as a set of hierarchical clauses; if
   this functionality is required, then a SUPABooleanClauseComposite
   object must be used.

   SUPAPolicyAtomic was abstracted from DEN-ng [2], and a version of
   this class is in the process of being added to the policy
   framework defined in the TM Forum ZOOM model [5].

   No attributes are currently defined for the SUPABooleanClauseAtomic
   class. Its primary purpose is to aggregate SUPAPolicyVariable,
   SUPAPolicyOperator, and SUPAPolicyValue objects to form a complete
   SUPABoolean clause. As such, this class is defined as abstract to
   simplify data model optimization and mapping.

6.5.3.2. The Abstract Class "SUPABooleanClauseComposite"

   This is a mandatory concrete class that represents a
   SUPABooleanClause that can operate as a hierarchy of PolicyClause
   objects, where the hierarchy contains instances of a
   SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite
   object. Each of the SUPABooleanClauseAtomic and
   SUPABooleanClauseComposite objects, including the outermost
   SUPABooleanClauseComposite object, are separately manageable. More
   importantly, the SUPABooleanClauseComposite object can aggregate
   any SUPABooleanClause subclass. Hence, it can be used to form
   hierarchies of SUPABooleanClauses.

   SUPABooleanClauseComposite was abstracted from DEN-ng [2], and a
   version of this class is in the process of being added to the
   policy framework defined in the TM Forum ZOOM model [5].

6.5.3.2.1. SUPABooleanClauseComposite Attributes

   A single attributes is currently defined for the
   SUPABooleanClauseComposite class, and is described in the
   following subsection.





Strassner                 Expires January 4, 2016            [Page 70]


Internet-Draft            SUPA Generic Policy Model          July 2015


6.5.3.2.1.1. The Attribute "supaBoolClauseIsCNF"

   This is a mandatory Boolean attribute. If its value is true, then
   this SUPABooleanClauseComposite is defined in Conjunctive Normal
   Form (i.e., and AND of ORs). Otherwise, it is defined in
   Disjunctive Normal Form (i.e., and OR of ANDs).


6.6. The Abstract Class "SUPAECAComponent"

   This is a mandatory abstract class that defines three subclasses,
   one each for the event, condition, and action portions of a
   SUPAECAPolicyRule. They are called SUPAEvent, SUPACondition, and
   SUPAAction, respectively. Its primary purpose is to serve as a
   convenient aggregation point, and thus has two uses:

      1. This enables a single aggregation (SUPAECAComponentsInTerms,
         see section 6.6.2.1) to be used to specify which object
         instances of which SUPAPolicyTerm subclasses are contained
         by a particular SUPAECAComponent object instance. Otherwise,
         a set of three aggregations would be required.
      2. This enables a single class (SUPAECAComponentsInTermsDetail,
         see section 6.6.2.1.1) to be used as a superclass to define
         which the specific semantics required by this combination
         of SUPAPolicyTerm and SUPAECAComponent subclasses.

6.6.1. SUPAECAComponent Attributes

   No attributes are currently defined for this class.

6.6.2. SUPAECAComponent Relationships

   A single aggregation is defined for this class, as specified
   below.

6.6.2.1. The Aggregation "SUPAECAComponentsInTerms"

   This is a mandatory aggregation that defines the set of
   SUPAPolicyTerms that are aggregated by this SUPAECAComponent.
   This enables complex combinations of SUPAPolicyTerms to be
   defined as SUPAEvents, SUPAConditions, or SUPAActions, which
   increases reusability. It also simplifies forming more complex
   Boolean clauses as combinations of SUPAEvents, SUPAConditions, or
   SUPAActions.







Strassner                 Expires January 4, 2016            [Page 71]


Internet-Draft            SUPA Generic Policy Model          July 2015


   The multiplicity of this relationship is 0..1 on the aggregate
   (SUPAECAComponent) side, and 0..n on the part (SUPAPolicyTerm)
   side. This means that this aggregation is completely optional.
   However, if it is instantiated, then zero or more SUPAPolicyTerms
   can be aggregated by a particular SUPAECAComponent. Similarly, a
   given SUPAPolicyTerm can be used by zero or more SUPAECAComponents.
   The 0..1 cardinality on the SUPAECAComponent side is necessary to
   enable SUPAPolicyTerm objects to exist (e.g., in a
   PolicyRepository) before they are used by a SUPAECAComponent. The
   semantics of this aggregation is defined by the
   SUPAECAComponentHasTermDetail association class.

6.6.2.1.1. The Association Class "SUPAECAComponentsInTermDetail"

   This is a mandatory association class that defines the semantics
   of the SUPAECAComponentsInTerms aggregation. This enables the
   attributes and relationships of the SUPAECAComponentsInTermDetail
   class to be used to constrain which SUPAPolicyTerm objects can be
   aggregated by this particular SUPAECAComponent object instance.
   Attributes will be added to this class at a later time.


6.6.3. SUPAECAComponent Subclasses

   There are three concrete subclasses of SUPAECAComponent; they are
   described in the following subsections.

6.6.3.1. The Concrete Class"SUPAEvent"

   THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT.


6.6.3.2. The Concrete Class"SUPACondition"

   THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT.


6.6.3.3. The Concrete Class"SUPAAction"

   THIS WILL BE DEFINED IN THE NEXT VERSION OF THIS DOCUMENT.











Strassner                 Expires January 4, 2016            [Page 72]


Internet-Draft            SUPA Generic Policy Model          July 2015


7. SUPA Logic Statement Information Model

   This section defines the classes, attributes, and relationships of
   the SUPA Logic Statement Information Model (LSIM).

7.1. Overview

   A Goal policy rule (also called a declarative policy rule, or an
   intent-based policy rule) is a declarative statement that defines
   what the policy should do, but not how to implement the policy. In
   this draft, such rules are called SUPA Logic Statements.

   This Section, and the following Sections, will be finished in the
   next version of this document.

7.2. Constructing a SUPAPLStatement

   This section will be finished in the next version of this document.


7.3. Working With SUPAPLStatements

   This section will be finished in the next version of this document.


7.4. The Abstract Class "SUPALogicClause"

   A SUPALogicStatement is an abstract class that represents
   declarative (also called intent-based) policies. A
   SUPALogicStatement MUST contain at least one SUPAPolicyStatement.
   Such policies define a goal to be achieved, or a set of actions to
   take, but do not prescribe how to achieve the goal or execute the
   actions. This differentiates it from a SUPAECAPolicyRule, which
   explicitly defines what triggers the evaluation of the
   SUPAECAPolicyRule, what conditions must be satisfied in order to
   execute the actions of the SUPAECAPolicyRule, and what actions to
   execute.

   This document defines two forms of a SUPALogicStatements. The first
   uses Propositional Logic (PL, see Section 3.2.4.2), while the
   second uses First-Order Logic (FOL, see Section 3.2.4.3).

   Note that this document does not refer to a SUPALogicStatement as
   a "rule", since both types of SUPALogicStatements defined in this
   document are technically not "rules". Rather, they are types of
   zero-order and first-order logic statements.





Strassner                 Expires January 4, 2016            [Page 73]


Internet-Draft            SUPA Generic Policy Model          July 2015


   If the SUPALogicStatement is expressed in PL, then it MUST consist
   of only the propositional connectives (i.e., negation, conjunction,
   disjunction, implication, and bi-implication (see Section 3.2.4.1).
   Furthermore, statements in a PL are limited to simple declarative
   propositions that MUST NOT use quantified variable or predicates.

   If the SUPALogicStatement is expressed in FOL, then it MUST consist
   of a set of logical predicates (i.e., a Boolean-valued function).
   The predicate can use all propositional connectives as well as two
   additional quantifiers (i.e., the universal quantifier and the
   existential quantifier).

   A logical predicate MUST consist of a head clause, and MAY also
   contain a body clause. This enables the semantics of a
   SUPALogicStatement to be clearly differentiated from the semantics
   of other types of SUPAPolicies that use SUPAPolicyStatements (and
   other parts of the SPGIM), such as SUPAECAPolicyRules. While in
   principle higher order logics can be defined, this document is
   limited to defining a SUPALogicStatement using either PL or FOL.



   When implemented in an information model, each PL or FOL statement
   MUST be defined as objects (i.e., a subclass of the
   SUPALogicStatement class; see Section 7). When an FOL statement is
   implemented in an information model, both the head and body clauses
   MUST be defined as objects (or sets of objects). However, a data
   model MAY map either a PL statement or an FOL statement to a more
   efficient form (e.g., by flattening the head and body objects into
   a single object).


7.5. The Abstract Class "SUPAPLStatement"

   This section will be finished in the next version of this document.

7.5.1. SUPAPLStatement Attributes

   This section will be finished in the next version of this document.

7.5.2. SUPAPLStatement Relationships

   This section will be finished in the next version of this document.








Strassner                 Expires January 4, 2016            [Page 74]


Internet-Draft            SUPA Generic Policy Model          July 2015


7.5.3. SUPAPLStatement Subclasses

   This section will be finished in the next version of this document.

7.5.3.1. The Concrete Class "SUPAArgument"


7.5.3.2. The Concrete Class "SUPAPLPremise"


7.5.3.3. The Concrete Class "SUPAPLConclusion"



7.6. Constructing a SUPAFOLStatement


7.7. Working With SUPAFOLStatements


7.7.1. SUPAFOLStatement Attributes


7.7.2. SUPAFOLStatement Relationships


7.7.3. SUPAFOLStatement Subclasses


7.7.3.1. The Concrete Class "SUPAGoalHead"


7.7.3.2. The Concrete Class "SUPAGoalBody"


7.8. Combining Different Types of SUPAFOLStatements















Strassner                 Expires January 4, 2016            [Page 75]


Internet-Draft            SUPA Generic Policy Model          July 2015


8. Examples


8.1. SUPAECAPolicyRule Examples



8.2. SUPALogicStatement Examples


8.3. Mixing SUPAECAPolicyRules and SUPALogicStatements



9. Security Considerations

   This will be defined in the next version of this document.


10. IANA Considerations

   This document has no actions for IANA.


11. Acknowledgments

   This document has benefited from reviews, suggestions, comments
   and proposed text provided by the following members, listed in
   alphabetical order: Andy Bierman, Bob Natale, Fred Feisullin,
   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.

   [RFC3060]   Moore, B., Ellesson, E., Strassner, J., Westerinen,
               A., "Policy Core Information Model -- Version 1
               Specification", RFC 3060, February 2001






Strassner                 Expires January 4, 2016            [Page 76]


Internet-Draft            SUPA Generic Policy Model          July 2015


   [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

   [RFC6020]   Bjorklund, M., "YANG - A Data Modeling Language for
               the Network Configuration Protocol (NETCONF)",
               RFC 6020, October 2010.

   [RFC6021]   Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
               October 2010.

12.2. Informative References

   [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., editors, "SUPA Proposition",
               IETF Internet draft, draft-klyus-supa-proposition-01,
               July 2015

   [9]         ISO/IEC 10746-3 (also ITU-T Rec X.903), "Reference
               Model Open Distributed Processing Architecture",
               April 20, 2010

Strassner                 Expires January 4, 2016            [Page 77]


Internet-Draft            SUPA Generic Policy Model          July 2015


Authors' Addresses

   John Strassner
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95138  USA
   Email: john.sc.strassner@huawei.com












































Strassner                 Expires November 09, 2015          [Page 78]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/