[Docs] [txt|pdf] [Tracker] [WG] [Email] [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: October 26, 2015                             April 26, 2015


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


Abstract

   The Simplified Use of Policy Abstractions (SUPA) addresses the
   needs of operators and application developers to represent
   multiple types of policy rules. This document defines a common
   structure for policy rules that is independent of language,
   protocol, and the level of abstraction of the content of the
   policy rule. This enables multiple policy rule data models to be
   constructed from it.



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.









Strassner, et al.         Expires September 18, 2015          [Page 1]


Internet-Draft           SUPA Generic Policy Model           Apr 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 ................................................. 5
   2. Conventions used in this document ............................ 5
   3. Terminology .................................................. 5
      3.1. Acronyms................................................. 5
      3.2. Definitions ............................................. 6
         3.2.1. Core Terminology  .................................. 6
            3.2.1.1. Information Model ............................. 6
            3.2.1.2. Data Model .................................... 6
            3.2.1.3. Container ..................................... 6
            3.2.1.4. PolicyContainer ............................... 7
         3.2.2. Policy Terminology ................................. 7
            3.2.2.1. SUPAPolicy .................................... 7
            3.2.2.2. SUPAPolicyStatement ........................... 7
            3.2.2.3. SUPAECAPolicyRule ............................. 8
            3.2.2.4. SUPAGoalPredicate ............................. 9
            3.2.2.5. SUPAMetadata .................................. 9
            3.2.2.6. SUPAPolicyTarget .............................. 9
            3.2.2.7. SUPAPolicySubject ............................ 10
         3.2.3. Modeling Terminology .............................. 10
            3.2.3.1. Inheritance .................................. 10
            3.2.3.2. Relationship ................................. 10
            3.2.3.3. Association .................................. 10
            3.2.3.4. Aggregation .................................. 11
            3.2.3.5. Composition .................................. 11
            3.2.3.6. Association Class ............................ 11
            3.2.3.7. Multiplicity ................................. 11
            3.2.3.8. Navigability ................................. 11
      3.3. Symbology .............................................. 11
   4. Policy Abstraction Architecture ............................. 12
      4.1. Motivation ............................................. 13
      4.2. SUPA Approach .......................................... 13
      4.3. Structure of SUPA Policies ............................. 14

Strassner, et al.         Expires September 18, 2015          [Page 2]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

Table of Contents (continued)

      4.4. SUPA Generic Policy Information Model Overview ......... 15
         4.4.1. Architectural Objectives .......................... 15
         4.4.2. Scope of Previous Work ............................ 15
         4.4.3. SGPIM Assumptions ................................. 16
   5. SGPIM Model ................................................. 17
      5.1. Overview ............................................... 17
      5.2. The Abstract Class "SUPAPolicy" ........................ 18
         5.2.1. SUPAPolicy Attributes ............................. 19
            5.2.1.1. The Attribute "supaObjectIDContent" .......... 19
            5.2.1.2. The Attribute "supaObjectIDFormat" ........... 19
            5.2.1.3. The Attribute "supaPolicyName" ............... 20
         5.2.2. SUPAPolicy Relationships .......................... 20
            5.2.2.1. The Relationship "HasSUPAPolicies" ........... 20
            5.2.2.2. The Association Class "HasSUPAPolicyDetail" .. 20
      5.3. The Abstract Class "SUPAPolicyAtomic" .................. 20
      5.4. The Abstract Class "SUPAPolicyComposite" ............... 21
      5.5. The Abstract Class "SUPAPolicyStatement" ............... 21
         5.5.1. SUPAPolicyStatement Attributes .................... 22
            5.5.1.1. The Attribute "supaPolicyStmtAdminStatus" .... 22
            5.5.1.2. The Attribute "supaPolicyStmtExecStatus" ..... 23
         5.5.2. SUPAPolicyStatement Subclasses .................... 24
            5.5.2.1. The Concrete Class "SUPAEncodedClause" ....... 24
               5.5.2.1.1. The Attribute "supaClauseContent" ....... 24
               5.5.2.1.2. The Attribute "supaClauseFormat" ........ 24
               5.5.2.1.3. The Attribute "supaClauseResponse" ...... 25
         5.5.3. SUPAPolicyStatement Relationships ................. 25
            5.5.3.1. The Aggregation "HasSUPAPolicyStatements" .... 25
            5.5.3.2. The Association Class
                      "HasSUPAPolicyStmtDetail" ................... 25
      5.6. The Abstract Class "SUPAPolicySubject" ................. 25
         5.6.1. SUPAPolicySubject Attributes ...................... 26
         5.6.2. SUPAPolicySubject Relationships ....................27
            5.6.2.1. The Relationship "HasSUPAPolicySubjects" ......27
            5.6.2.2. The Association Class
                      "HasSUPAPolicySubjDetail" ....................27
      5.7. The Abstract Class "SUPAPolicyTarget" .................. 31
         5.7.1. SUPAPolicyTarget Attributes ....................... 28
            5.7.1.1. The Attribute "supaPolicyTargetEnabled" ...... 28
         5.7.2. SUPAPolicyTarget Relationships .................... 28
            5.7.2.1. The Relationship "HasSUPAPolicyTargets" ...... 28
            5.7.2.2. The Association Class "HasSUPAPolicyTgtDetail" 28
      5.8. The Abstract Class "SUPAPolicyMetadata" ................ 28
   6. SUPA ECAPolicyRule Information Model ........................ 29
      6.1. Overview ............................................... 29
      6.2. Constructing a SUPAECAPolicyRule ....................... 29
      6.3. Working With SUPAECAPolicyRules ........................ 30
      6.4. The Concrete Class "SUPAECAPolicyRule" ................. 31
         6.4.1. SUPAECAPolicyRule Attributes ...................... 31


Strassner, et al.         Expires September 18, 2015          [Page 3]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

Table of Contents (continued)

            6.4.1.1. The Attribute "supaECAPRDeployStatus"......... 31
            6.4.1.2. The Attribute "supaECAPRExecStatus"........... 32
         6.4.2. SUPAECAPolicyRule Relationships ................... 32
            6.4.2.1. The Relationship "HasSUPAEvents" ............. 32
            6.4.2.2. The Relationship "HasSUPAConditions" ......... 32
            6.4.2.3. The Relationship "HasSUPAActions" ............ 33
      6.5. SUPAPolicyStatement Subclasses ......................... 33
         6.5.1. Designing SUPAPolicyStatements Using
                 SUPABooleanClauses ............................... 33
      6.6. The Abstract Class "SUPABooleanClause" ................. 34
         6.6.1. SUPABooleanClause Attributes ...................... 35
            6.6.1.1. The Attribute "supaBoolIsNegated" ............ 35
         6.6.2. SUPABooleanClause Relationships ................... 35
            6.6.2.1. The Relationship "HasSUPABooleanClauses" ..... 35
      6.7. SUPABooleanClause Subclasses ........................... 35
         6.7.1. The Abstract Class "SUPABooleanClauseAtomic" ...... 36
            6.7.1.1. The Abstract Class "SUPAPolicyVariable" ...... 36
               6.7.1.1.1. Problems with the RFC3460 Version of
                           PolicyVariable ......................... 37
               6.7.1.1.2. The Abstract Class "SUPAPolicyVariable" . 37
            6.7.1.2. The Concrete Class "SUPAPolicyOperator" ...... 36
            6.7.1.3. The Abstract Class "SUPAPolicyValue" ......... 38
               6.7.1.3.1. Problems with the RFC3460 Version of
                          PolicyValue ............................. 38
               6.7.1.3.2. The Abstract Class "SUPAPolicyValue" .... 38
         6.7.2. The Abstract Class "SUPABooleanClauseComposite" ... 38
            6.7.2.1. SUPABooleanClauseComposite Attributes ........ 38
            6.7.2.2. SUPABooleanClauseComposite Relationships ..... 38
   7. SUPA Goal Predicate Information Model ....................... 39
      7.1. Overview ............................................... 39
      7.2. Constructing a SUPAGoalPredicate ....................... 39
      7.3. Working With SUPAGoalPredicates ........................ 39
      7.4. The Abstract Class "SUPAGoalPredicate" ................. 39
   8. Security Considerations  .................................... 39
   9. IANA Considerations ......................................... 39
   10. Acknowledgments ............................................ 39
   11. References ................................................. 40
      11.1. Normative References .................................. 40
      11.2. Informative References  ............................... 40
   Authors' Addresses ............................................. 41













Strassner, et al.         Expires September 18, 2015          [Page 4]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

1. Introduction

   The Shared Unified Policy Automation (SUPA) addresses the needs of
   operators and application developers to represent multiple types
   of policy rules. This document defines a common structure for
   policy rules that is independent of language, protocol, and the
   level of abstraction of the content of the policy rule. This
   enables multiple policy rule data models to be constructed from it.


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
   ECA        Event-Condition-Action
   EPRIM      ECA Policy Rule Information Model
   FOL        First Order Logic
   GPIM       Goal Predicate Policy Information Model
   Netconf    Network Configuration protocol
   OAM        Operational, Administrative, and Management
   OID        Object IDentifier
   PAP        Policy Administration Point
   PDP        Policy Decision Point
   PEP        Policy Enforcement Point
   PIP        Policy Information Point
   PR         Policy Repository
   PXP        Policy Execution Point
   SGPIM      SUPA Generic Policy Information Model
   SUPA       Simplified Use of Policy Abstractions
   UML        Unified Modeling Language
   URI        Uniform Resource Identifier
   YANG       A data definition language for use with Netconf.






Strassner, et al.         Expires September 18, 2015          [Page 5]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


3.2. Definitions

   This section defines important terms that are used in this document.

3.2.1. Core Terminology

   The following terms 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]. 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.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.




Strassner, et al.         Expires September 18, 2015          [Page 6]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

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 features 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 (SGPIM). Note that the
   prefix "SUPA" is used for all classes and relationships defined
   in the SGPIM in  order to ensure name uniqueness. Similarly, the
   prefix "supa" is defined for all SUPA class attributes.

3.2.2.1. SUPAPolicy

   A SUPAPolicy is an abstract class that is a type of
   PolicyContainer. A SUPAPolicy MUST have one or more
   SUPAPolicyStatements that define the content of the Policy.

   SUPAPolicy is defined generically as a means to manage 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.

   A SUPAPolicy MUST have at least one SUPAPolicyStatement. A
   SUPAPolicy MAY be qualified by a set of zero or more
   SUPAPolicySubjects, SUPAPolicyTargets, and/or SUPAPolicyMetadata
   objects (all of which are defined as abstract classes). When
   defined in an information model, the SUPAPolicy class MUST have
   separate aggregation relationships with the SUPAPolicySubject,
   SUPAPolicyTarget, and SUPAPolicyMetadata classes. 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.

3.2.2.2. SUPAPolicyStatement

   A SUPAPolicyStatement is an abstract class that contains an
   individual or group of related functions; this set of functions
   defines a set of actions to take. Examples of actions include
   getting information, stating facts about the system being managed,
   writing a change to a configuration of one or more managed objects,
   and querying information about a set of managed objects.

Strassner, et al.         Expires September 18, 2015          [Page 7]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


   SUPAPolicyStatements are objects in their own right, which
   facilitates their reuse. SUPAPolicyStatements can also be combined
   in a whole-part (containment) relationship under a SUPAPolicy,
   thereby forming a SUPAECAPolicyRule or a SUPAGoalPredicate. 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).

3.2.2.3. SUPAECAPolicyRule

   An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an
   abstract class that is made up of at least one SUPAPolicyStatement.
   In other words, a SUPAECAPolicyRule is a type of PolicyContainer
   whose content is defined by one or more SUPAPolicyStatements.

   A SUPAECAPolicyRule is a three-tuple, and MUST contain an event
   clause, a condition clause, and an action clause. Each of these
   three clauses MUST have at least one term corresponding to the
   type of clause that it is; it MAY have more than one. If there
   are more than one term, then they MUST be combined using Boolean
   AND, OR, and NOT operators. For example, a valid event clause
   could be: "three events of type A AND NOT an event of type B".
   These three clauses enable the semantics of a SUPAECAPolicyRule
   to be clearly differentiated from the semantics of other types of
   SUPAPolicies that use SUPAPolicyStatements (and other parts of
   the SPGIM), such as SUPAGoalPredicates.

   The semantics of a SUPAECAPolicyRule are defined as follows:
      o the event clause defines a Boolean statement that, if true,
        triggers the evaluation of the condition clause of the
        SUPAECAPolicyRule
      o the condition clause defines a Boolean statement that, if
        true, enables the actions of the SUPAECAPolicyRule to be
        executed
      o the action clause is an aggregation of actions that may be
        executed if the event and condition clauses so dictate; the
        behavior of the actions is defined using the SUPAMetadata
        that has been aggregated by the SUPAECAPolicyRule

   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., flattening these
   three types of object instances into a single object instance).




Strassner, et al.         Expires September 18, 2015          [Page 8]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


3.2.2.4. SUPAGoalPredicate

   A SUPAGoalPredicate is an abstract class that is made up of at
   least one SUPAPolicyStatement. In other words, a SUPAGoalPredicate
   is a type of PolicyContainer whose content is defined by one or
   more SUPAPolicyStatements.

   A SUPAGoalPredicate defines what actions to take, but not how to
   execute those actions. It is commonly called declarative, or
   intent-based, policy.

   If the SUPAGoalPredicate is expressed in first order logic (FOL),
   then a SUPAGoalPredicate MUST consist of a head clause, and MAY
   also contain a body clause. This enables the semantics of a
   SUPAGoalPredicate 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 SUPAGoalPredicate using just FOL. When
   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 these definitions to a more efficient form
   (e.g., flattening the head and body objects into a single object).

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.





Strassner, et al.         Expires September 18, 2015          [Page 9]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


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

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 (SGPIM).

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). A subclass does NOT change the
   characteristics or behavior of the superclass that it inherits
   from. However, a subclass MAY add new attributes and relationships
   that distinguish it from the attributes and relationships defined
   by 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.

3.2.3.3. Association

   An association represents a generic dependency between a first
   and a second set of entities.

Strassner, et al.         Expires September 18, 2015         [Page 10]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


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

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.

3.2.3.6. 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.3. Symbology

   To be Done


















Strassner, et al.         Expires September 18, 2015         [Page 11]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

4. Policy Abstraction Architecture

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

      o The SGPIM 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 either an event-condition-action tuple, a FOL
        predicate, or a combination of these statements.
      o Since these two representations are very different in syntax
        and content, the content of a Policy is abstracted from its
        representation:
          o Both SUPAECAPolicyRules and SUPAGoalPredicates are types
            of SUPAPolicies
          o Both SUPAECAPolicyRules and SUPAGoalPredicates are
            constructed from SUPAPolicyStatements
          o The syntax of a SUPAECAPolicyRule, and hence its
            representation, is different from that of a
            SUPAGoalPredicate
          o A SUPAPolicy MAY use SUPAECAPolicyRules and/or
            SUPAGoalPredicates
          o A SUPAPolicy consists of one or more SUPAPolicyStatements,
            one or more SUPAPolicyTargets, an optional
            SUPAPolicySubject, and optional SUPAPolicyMetadata
      o A SUPAPolicy MUST contain at least one SUPAPolicyStatement;
        it MAY contain more than one.
      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 SUPAGoalPredicate 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, et al.         Expires September 18, 2015         [Page 12]


Internet-Draft           SUPA Generic Policy Model           Apr 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.

   Both of these examples are commonly referred to as "policy rules",
   but they take very different forms, since they are at very
   different levels of abstraction and likely 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
   algorithms implemented in a particular device).

   Note that these two policy rules could 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. Hence,
   the need for a common policy framework.

4.2. SUPA Approach

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





Strassner, et al.         Expires September 18, 2015         [Page 13]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

   It may be necessary to translate the form of a PolicyRule 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, or the Congress
   version of Datalog). 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. A common framework for expressing policies
   that is independent of the level of abstraction is required in
   order to form such a continuum.


4.3. Structure of SUPA Policies

   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.

           +-----------------------------------------------+
           | SUPA Generic Policy Information Model (SGPIM) |
           +-----------------------------------------------+
                                 / \
                                  |
                                  |
                    +-------------+------------+
                    |                          |
                    |                          |
    +---------------+-----------+  +-----------+--------------+
    |    SUPAECAPolicyRule      |  |    SUPAGoalPredicate     |
    | Information Model (EPRIM) |  | Information Model (GPRIM)|
    +---------------------------+  +--------------------------+
               / \                              / \
                |                                |
                |                                |
    +-----------+-----------+        +-----------+------------+
    |     ECAPolicyRule     |        |     GoalPredicate      |
    |       Data Model      |        |       Data Model       |
    +-----------------------+        +------------------------+

          Figure 1: Overview of SUPA Policy Rule Abstractions

   Conceptually, the SGPIM 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 SUPAGoalPredicates
   (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, et al.         Expires September 18, 2015         [Page 14]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


   The SGPIM defines a SUPAPolicy object as a PolicyContainer that
   specifies the structure, content, and metadata of a collection of
   policies. The content of a SUPAPolicy is made up of one or more
   SUPAPolicyStatements. A SUPAPolicyStatement may, in this release
   of SUPA, take one of two forms: SUPAECAPolicyRules (see
   Section 6) and SUPAGoalPredicates (see Section 7).

4.4. SUPA Generic Policy Information Model Overview

   This section describes the overall design of the SGPIM.

4.4.1. Architectural Objectives

   The purpose of the SGPIM is to define the common characteristics
   and behavior of Policy independent of how Policy is written.
   Specifically, the SGPIM generalizes the concept of Policy to
   enable different forms of Policy to be defined that refine its
   definition. The implementation of Policy by SGPIM is called SUPA
   Policy. For this document, two exemplar forms of SUPAPolicy are
   defined: SUPAECAPolicyRules and SUPAGoalPredicates.


4.4.2. Scope of the Previous Work

   To be done. Section 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, et al.         Expires September 18, 2015         [Page 15]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


4.4.3. SGPIM Assumptions

   SUPA DOES NOT assume that it is the "root class of everything".
   Rather, the design of this information model assumes that the SUPA
   classes are inserted into another model at a given point in the
   other model.

   However, most models do not have a capability to integrate
   different namespaces. 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. This is shown in
   Figure 2:

             +------------------------------------------+
             |     Root Class of an Existing Model      |
             +------------------------------------------+
                                 / \
                                  |
                                  |
                +-----------------+--------------+
                |                                |
                |                                |
    +-----------+-----------+        +-----------+------------+
    |    A Subclass of the  |        |    A Subclass of the   |
    |     Existing Model    |        |      Existing Model    |
    +-----------------------+        +------------------------+
                                                / \
                                                 |
                                                 |
                                                ...
                                                 |
                                                 |
                                     +-----------+------------+
                                     |  SUPA Class Hierarchy  |
                                     |   (SGPIM plus EPRIM    |
                                     |      and/or GPRIM)     |
                                     +------------------------+

          Figure 2: Integrating SUPA into an Existing Model









Strassner, et al.         Expires September 18, 2015         [Page 16]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


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

5.1. Overview
   The overall class definition is shown in Figure 3. 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 3, 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)
       |     |
       |     +---SUPAPolicyMetadata (see Section 5.8)
       |
      ...

         Figure 3: Integrating SUPA into an Existing Model

The following subsections define the classes of the SGPIM. 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.

















Strassner, et al.         Expires September 18, 2015         [Page 17]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


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.

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

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

              Figure 4: The SUPAPolicy Class Hierarchy


   Note that a SUPAPolicy is a PolicyContainer object. A
   SUPAPolicyAtomic as well as a SUPAPolicyComposite are also
   PolicyContainer objects.





Strassner, et al.         Expires September 18, 2015         [Page 18]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


   In figure 4:

      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)


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

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









Strassner, et al.         Expires September 18, 2015         [Page 19]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


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


5.2.2. SUPAPolicy Relationships

   This section defines the relationships of the SUPAPolicy class.

5.2.2.1. The Relationship "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.

5.2.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.3. The Abstract Class "SUPAPolicyAtomic"

   This is a mandatory abstract class. This class is a type of
   PolicyContainer.

   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.



Strassner, et al.         Expires September 18, 2015         [Page 20]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


   No attributes are currently defined for the SUPAPolicyAtomic class.
   It serves as a superclass for the different types of SUPA Policies
   that are defined. In this release, both a SUPAECAPolicyRule (see
   Section 6) as well as a SUPAGoalPredicate (see Section 7) are
   defined as subclasses of the SUPAPolicyAtomic class.


5.4. The Abstract Class "SUPAPolicyComposite"

   This is a mandatory abstract class. This class is a type of
   PolicyContainer.

   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.

   No attributes are currently defined for the SUPAPolicyAtomic class.
   It is used to create hierarchical SUPA Policies.


5.5. The Abstract Class "SUPAPolicyStatement"

   This is a mandatory abstract class that separates the
   representation of a SUPAPolicy from its implementation. Its
   subclasses enable the developer to define a SUPAPolicy as either a
   completely reusable set of SUPAPolicy objects or as an efficient
   encoding made up of attributes.

   Both SUPAECAPolicyRules (see Section 6) and SUPAGoalPredicates
   (see section 7) MAY use a SUPAEncodedClause (see Section 5.5.1);
   the former MAY also use a SUPABooleanClause (see Section 6.4),
   while the latter MAY also use a SUPAFOLClause (see Section 7.4).

   A class diagram showing SUPAPolicyStatement is shown in Figure 5.
   Note that in this figure:

      o SUPAPolicyStatement, SUPAPolicyAtomic, and
        SUPAPolicyComposite are subclasses of SUPAPolicy
      o A SUPAEncodedClause is a subclass of SUPAPolicyStatement,
        and may be used by either a SUPAECAPolicyRule or a
        SUPAGoalPredicate
      o Both the HasSUPAPolicyStatements and the HasSUPAPolicies
        aggregations are implemented as association classes






Strassner, et al.         Expires September 18, 2015         [Page 21]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

        +-------------------------+       +---------------------+
        | HasSUPAPolicyStmtDetail |       | HasSUPAPolicyDetail |
        +-----+-------------------+       +----------+----------+
              |                                      |
              |        1  +-----------------+        |
              |        / \|                 |/       |
      +-------+-------- A |    SUPAPolicy   |--------+-----------+
      |                \ /|                 |\                   |
      |                   +-----------------+ 1..n               |
      |                          / \                             |
      | HasSUPAPolicyStatements   |              HasSUPAPolicies |
      |                           |                              |
      |                    +------+------+--------+              |
      |                    |             |        |              |
      |    1..n +----------+----------+  |        |              |
      |        \|                     |  |        |              |
      +---------| SUPAPolicyStatement |  |        |              |
               /|                     |  |        |              |
                +---------------------+  |        |              |
                     / \                 |        |              |
                      |      +-----------+------+ |              |
                      |      | SUPAPolicyAtomic | |              |
                      |      +------------------+ |              |
                      |                           |              |
          +-----------+-------+    +--------------+------+       |
          | SUPAEncodedClause |    |                     |/ \    |
          +-------------------+    | SUPAPolicyComposite | A ----+
                                   |                     |\ /
                                   +---------------------+  0..1

        Figure 5: SUPAPolicyStatements and SUPAPolicy Classes


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.








Strassner, et al.         Expires September 18, 2015         [Page 22]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


   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 SUPAGoalPredicate) 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
   4 means that this SUPAPolicyStatement is in a special test mode.

5.5.1.2. The Attribute "supaPolicyStmtExecStatus"

   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 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 SUPAGoalPredicate) 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: Working (i.e., in use and no errors reported)
      2: Not Working (i.e., in use, but errors have been reported)
      3: In Test (i.e., no operational traffic can be passed)
      4: Available (i.e., could be used, but currently isn't)
      5: Not Available (i.e., not available for use)

   Value 0 denotes an error that prevents this SUPAPolicyStatement
   from being used. 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. 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.









Strassner, et al.         Expires September 18, 2015         [Page 23]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

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 SUPAGoalPredicate). The SGPIM defines one
   common subclass of SUPAPolicyStatement, called a SUPAEncodedClause,
   that can be used by both SUPAECAPolicyRules as well as
   SUPAGoalPredicates. Clauses dedicated to the specific use of a
   SUPAECAPolicyRule and a SUPAGoalPredicate are defined in
   Sections 6 and 7, respectively.

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.

   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.

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

Strassner, et al.         Expires September 18, 2015         [Page 24]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


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

5.5.3. SUPAPolicyStatement Relationships

   This section defines the relationships of SUPAPolicyStatement.

5.5.3.1. The Aggregation "HasSUPAPolicyStatements"

   This is a mandatory aggregation that defines the set of
   SUPAPolicyStatements that are contained in the instance of this
   particular SUPAPolicy object. This defines a SUPAPolicy object as
   being made up of at least one SUPAPolicyStatement. The multiplicity
   of this relationship is defined as 1 on the aggregate (SUPAPolicy)
   side, and 1..n on the part (SUPAPolicyStatement) side. This means
   that this relationship is mandatory, and each SUPAPolicy object is
   made up of at least one SUPAPolicyStatement object. The semantics
   of this aggregation are implemented using the
   HasSUPAPolicyStmtDetail association class.

5.5.3.2. The Association Class "HasSUPAPolicyStmtDetail"

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

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. A SUPAPolicySubject SHOULD be mapped to a role
   (e.g., using the role-object pattern, as DEN-ng does). A class
   diagram is shown in Figure 6.









Strassner, et al.         Expires September 18, 2015         [Page 25]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


     +------------------------+
     | HasSUPAPolicyTgtDetail |
     +-----------+------------+
                 |
                 |           0..1  +------------+
                 |              / \|            |
    +------------+-------------- A |            |
    |  HasSUPAPolicyTargets     \ /|            |
    |                              | SUPAPolicy |
    |                        0..1  |            |
    |  HasSUPAPolicySubjects    / \|            |
    | +------------+------------ A |            |
    | |            |            \ /|            |
    | |            |               +------------+
    | |            |                     / \
    | | +----------+--------------+       |
    | | | HasSUPAPolicySubjDetail |       |
    | | +-------------------------+       |
    | |                                   |
    | |              +--------------------+----+--------------+
    | |              |                         |              |
    | |              |                         |              |
    | | 0..n +-------+---------+ 0..n +--------+-------+   (other
    | |     \|                 |     \|                | SUPAPolicy
    | +------|SUPAPolicySubject|  +---|SUPAPolicyTarget| subclasses)
    |       /|                 |  |  /|                |
    |        +-----------------+  |   +----------------+
    |                             |
    +-----------------------------+

          Figure 6.  SUPAPolicySubject and SUPAPolicyTarget

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

5.6.1. SUPAPolicySubject Attributes

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



Strassner, et al.         Expires September 18, 2015         [Page 26]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

5.6.2. SUPAPolicySubject Relationships

   This section defines the relationships of the SUPAPolicySubject
   class.

5.6.2.1. The Relationship "HasSUPAPolicySubjects"

   This is an optional aggregation that defines the set of
   SUPAPolicySubjects that are contained in the instance of this
   particular SUPAPolicy object. This defines the set of entities
   that authored 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 (SUPAPolicySubject) 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 aggregation
   are implemented using the HasSUPAPolicySubjDetail association class.

5.6.2.2. The Association Class "HasSUPAPolicySubjDetail"

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

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


5.7. The Abstract Class "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 between the
   SUPAPolicySubject and the SUPAPolicyTarget, wherein the
   SUPAPolicyTarget consents 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 SUPAPolicySubject SHOULD be mapped to a role (e.g., using the
   role-object pattern). Figure 6 shows a class diagram of the
   SUPAPolicyTarget.

Strassner, et al.         Expires September 18, 2015         [Page 27]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

5.7.1. SUPAPolicyTarget Attributes

   The following subsections define the attributes of a
   SUPAPolicyTarget.

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

5.7.2. SUPAPolicyTarget Relationships

   This section defines the relationships of the SUPAPolicyTarget
   class.

5.7.2.1. The Relationship "HasSUPAPolicyTargets"

   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 "HasSUPAPolicyTgtDetail"

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

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

5.8. The Abstract Class "SUPAPolicyMetadata"

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








Strassner, et al.         Expires September 18, 2015         [Page 28]


Internet-Draft           SUPA Generic Policy Model           Apr 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 SGPIM for representing the components of a
   Policy that uses ECA semantics. Specifically, the EPRIM specializes
   the SUPAPolicyAtomic class to create a SUPAECAPolicyRule; it also
   specializes a SUPAPolicyStatement to create a SUPAECAComponent. The
   SUPAECAPolicyRule uses the rest of the SGPIM infrastructure to
   define a complete Policy model according to ECA semantics.
   Specifically:
      o Event, condition, and action clauses are subclasses of
        SUPAPolicyStatement
      o An optional set of SUPAPolicySubjects can be defined to
        represent the authoring of a SUPAECAPolicyRule
      o An optional set of 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


6.2. Constructing a SUPAECAPolicyRule

   A SUPAECAPolicyRule is constructed as follows:
      o Define three types of SUPABooleanClauses (see Section 6.4),
        one each for the event, condition, and action clauses that
        make up a SUPAECAPolicyRule (see Section 6.3)
      o Define a set of SUPAEvent objects (see Section 6.5.2), and
        associate them with the SUPABooleanClause that represents the
        event clause of the SUPAECAPolicyRule
      o Define a set of SUPACondition objects (see Section 6.5.3),
        and associate them with the SUPABooleanClause that represents
        the condition clause of the SUPAECAPolicyRule
      o Define a set of SUPAAction objects (see Section 6.5.4), and
        associate them with the SUPABooleanClause that represents the
        action clause of the SUPAECAPolicyRule
      o Define a SUPAECAPolicyRule, which is a subclass of the SGPIM
        SUPAPolicyAtomic class (see Section 5.3)
      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

Strassner, et al.         Expires September 18, 2015         [Page 29]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

6.3. Working With SUPAECAPolicyRules

   A SUPAECAPolicyRule is a type of SUPAPolicy. It is a tuple that has
   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.

   Each of the three clauses is constructed from one or more
   SUPABooleanClauses. Since a SUPABooleanClause is a subclass of
   SUPAPolicyStatement (see Section 5.5), and a SUPABooleanClause can
   aggregate SUPAEncodedClauses (see Sections 5.5.2 and 6.3.2.2), a
   SUPAECAPolicyRule is built entirely from components defined in the
   SGPIM. As will be shown in Section 7.3, this is also true for
   SUPAGoalPredicates. The construction of a SUPAECAPolicyRule is
   shown in Figure 7, and is explained in Section 6.4.

      +----------------------+           +---------------------+
      |   SUPAPolicyAtomic   |           | SUPAPolicyStatement |
      +----------------------+           +---------------------+
                 / \                                / \
                  |                                  |
                  |                                  |
     +------------+------------+        +------------+------------+
     |    SUPAECAPolicyRule    |        |    SUPABooleanClause    |
     +-------------------------+        +-------------------------+
       0..1/ \ 0..1/ \ 0..1/ \            1..n/ \ 1..n/ \ 1..n/ \
           \ /     \ /     \ /                 |       |       |
            |       |       |                  |       |       |
            |       |       |  HasSUPAEvents   |       |       |
            |       |       +------------------+       |       |
            |       |         HasSUPAConditions        |       |
            |       +----------------------------------+       |
            |                  HasSUPAActions                  |
            +--------------------------------------------------+

                Figure 7.  SUPAECAPolicyRule Clauses







Strassner, et al.         Expires September 18, 2015         [Page 30]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

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,
   PolicyMetadata. As such, it doesn't have an inherent relationship
   with PolicySubject or PolicyTarget; these all represent the
   specific semantics for a particular SUPAECAPolicyRule. Hence,
   these semantics are defined in an instance of the
   SUPAPolicyComposite class if they are required.

   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 a SUPABooleanClause
   (see Section 6.4).

6.4.1. SUPAECAPolicyRule Attributes

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

6.4.1.1. The Attribute "supaECAPRDeployStatus"

   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












Strassner, et al.         Expires September 18, 2015         [Page 31]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


6.4.1.2. The Attribute "supaECAPRExecStatus"

   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)

6.4.2. SUPAECAPolicyRule Relationships

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

6.4.2.1. The Relationship "HasSUPAEvents"

   This is a mandatory aggregation that defines the set of
   SUPABooleanClauses that are aggregated by this SUPAECAPolicyRule
   to form an Event clause. The multiplicity of this relationship is
   0..1 on the aggregate (SUPAECAPolicyRule) side, and 1..n on the
   part (SUPABooleanClause) side. This means that one or more
   SUPABooleanClauses are aggregated and used to define this
   SUPAECAPolicyRule. The 0..1 cardinality on the SUPAECAPolicyRule
   side is necessary to enable SUPABooleanClauses to exist (e.g., in
   a PolicyRepository) before they are used by a SUPAECAPolicyRule.

6.4.2.2. The Relationship "HasSUPAConditions"

   This is a mandatory aggregation that defines the set of
   SUPABooleanClauses that are aggregated by this SUPAECAPolicyRule
   to form a Condition clause. The multiplicity of this relationship
   is 0..1 on the aggregate (SUPAECAPolicyRule) side, and 1..n on the
   part (SUPABooleanClause) side. This means that one or more
   SUPABooleanClauses are aggregated and used to define this
   SUPAECAPolicyRule. The 0..1 cardinality on the SUPAECAPolicyRule
   side is necessary to enable SUPABooleanClauses to exist (e.g., in
   a PolicyRepository) before they are used by a SUPAECAPolicyRule.









Strassner, et al.         Expires September 18, 2015         [Page 32]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

6.4.2.3. The Relationship "HasSUPAActions"

   This is a mandatory aggregation that defines the set of
   SUPABooleanClauses that are aggregated by this SUPAECAPolicyRule
   to form an Action clause. The multiplicity of this relationship is
   0..1 on the aggregate (SUPAECAPolicyRule) side, and 1..n on the
   part (SUPABooleanClause) side. This means that one or more
   SUPABooleanClauses are aggregated and used to define this
   SUPAECAPolicyRule. The 0..1 cardinality on the SUPAECAPolicyRule
   side is necessary to enable SUPABooleanClauses to exist (e.g., in
   a PolicyRepository) before they are used by a SUPAECAPolicyRule.


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
   SGPIM SUPAPolicyStatement class for use in constructing (only)
   SUPAECAPolicyRule objects.

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

   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 EPRIM (specifically, of the
   SUPABooleanClauseAtomic class, which is defined in Section 6.7.1).
   This enables the EPRIM, in conjunction with the SGPIM, to be
   used as a reusable class library. Put another way, 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 class attribute.









Strassner, et al.         Expires September 18, 2015         [Page 33]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

   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.7.1 and
   6.7.2, respectively. This enables instances of either a
   SUPABooleanClauseAtomic and/or a SUPABooleanClauseComposite to be
   aggregated into a SUPABooleanClauseComposite object.


6.6. The Abstract Class "SUPABooleanClause"

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

         {PolicyVariable, PolicyOperator, PolicyValue}

   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.

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

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

   Figure 8.  The Composite Pattern Applied to a SUPABooleanClause








Strassner, et al.         Expires September 18, 2015         [Page 34]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


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

6.6.1. SUPABooleanClause Attributes

   The following sections define attributes of a SUPABooleanClause.

6.6.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.6.2. SUPABooleanClause Relationships

   The following subsections define the relationships of a
   SUPABooleanClause.

6.6.2.1. The Relationship "HasSUPABooleanClauses"

   This is a mandatory aggregation that defines the set of
   SUPABooleanClauses that are aggregated by this    SUPABooleanClauseComposite to form a complete SUPABooleanClause
   from multiple clauses (which can be made up of
   SUPABooleanClauseAtomic and/or SUPABooleanClauseComposite object
   instances. 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.

6.7. SUPABooleanClause Subclasses

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









Strassner, et al.         Expires September 18, 2015         [Page 35]


Internet-Draft           SUPA Generic Policy Model           Apr 2015

6.7.1. The Abstract Class "SUPABooleanClauseAtomic"

   This is a mandatory abstract 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.

   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.

   The three primary subclasses of the SUPABooleanClauseAtomic class
   are shown in Figure 9.

                       +-------------------------+
                       | SUPABooleanClauseAtomic |
                       +-------------------------+
                                   / \
                                    |
                                    |
                   +-------------+--+-----------+
                   |             |              |
                   |             |              |
        +----------+---------+   |              |
        | SUPAPolicyVariable |   |              |
        +--------------------+   |              |
                                 |              |
                      +----------+---------+    |
                      | SUPAPolicyOperator |    |
                      +------------------- +    |
                                                |
                                       +--------+--------+
                                       | SUPAPolicyValue |
                                       +---------------- +

          Figure 9.  SUPABooleanClauseAtomic Subclasses

6.7.1.1. The Abstract Class "SUPAPolicyVariable"

   This is a mandatory abstract class. It is similar to the
   PolicyVariable class of [RFC3460], but there are some important
   differences in the SUPA version of this class that make the SUPA
   version more generic than the version defined in [RFC3460]. The
   problems in the definition of the [RFC3460] version of this class
   are discussed in Section 6.7.1.1.1, and the SUPAPolicyVariable
   class definition is defined in Section 6.7.1.1.2.

Strassner, et al.         Expires September 18, 2015         [Page 36]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


6.7.1.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
   broader things than "just" a flow or an event. This is reflected
   in the SUPAPolicyVariable definition.

   Third, in [RFC3460], defining constraints for a variable is
   limited to associating the variable with a PolicyValue. This is
   both cumbersome (because associations are costly), 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.

   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)

6.7.1.1.2. The Abstract Class "SUPAPolicyVariable"

   To be finished in the next version of this document.

   The big question to be answered is whether to keep the
   PolicyImplicitVariable and PolicyExplicitVariable subclasses of
   [RFC3460] or not.

6.7.1.2. The Concrete Class "SUPAPolicyOperator"

   This is a mandatory abstract class. Note that there is no
   equivalent to this class in [RFC3460], which causes a number of
   problems in the overloading of the semantics of an operator for
   defining clauses in an ECA policy rule.

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






Strassner, et al.         Expires September 18, 2015         [Page 37]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


6.7.1.3. The Abstract Class "SUPAPolicyValue"

   This is a mandatory abstract class. It is similar to the
   PolicyValue class of [RFC3460], but there are some important
   differences in the SUPA version of this class that make the SUPA
   version more generic than the version defined in [RFC3460]. The
   problems in the definition of the [RFC3460] version of this class
   are discussed in Section 6.7.1.3.1, and the SUPAPolicyVariable
   class definition is defined in Section 6.7.1.3.2.

6.7.1.3.1. Problems with the RFC3460 Version of PolicyValue

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

6.7.1.3.2. The Abstract Class "SUPAPolicyValue"


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


6.7.2. The Abstract Class "SUPABooleanClauseComposite"

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

6.7.2.1. SUPABooleanClauseComposite Attributes

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

6.7.2.2. SUPABooleanClauseComposite Relationships

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




















Strassner, et al.         Expires September 18, 2015         [Page 38]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


7. SUPA GoalPredicate Information Model

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

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


7.2. Constructing a SUPAGoalPredicate

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


7.3. Working With SUPAGoalPredicates

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


7.4. The Abstract Class "SUPAGoalPredicate"

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


8. Security Considerations

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

9. IANA Considerations

   This document has no actions for IANA.

10. Acknowledgments

   This document has benefited from reviews, suggestions, comments
   and proposed text provided by the following members, listed in
   alphabetical order: TBD.










Strassner, et al.         Expires September 18, 2015         [Page 39]


Internet-Draft           SUPA Generic Policy Model           Apr 2015


11. References

This section defines normative and informative references for this document.

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

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

11.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.43,
               http://dmtf.org/standards/cim/cim_schema_v2430







Strassner, et al.         Expires September 18, 2015         [Page 40]


Internet-Draft           SUPA Generic Policy Model           Apr 2015




Authors' Addresses

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









































Strassner, et al.         Expires September 18, 2015         [Page 41]

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