One document matched: draft-chen-supa-eca-data-model-00.txt


Network Working Group                                          M. Chen 
Internet Draft                                              BBIX, Inc.
Intended status: Standard Track                            L.Contreras            
Expires: January 2, 2016                                Telefonica I+D
            						  M. Fukushima
						   KDDI R&D Labs. Inc.
                                                                      
                                                          July 2, 2015 
 
                                    
                       ECA Policy YANG Data Model 
                  draft-chen-supa-eca-data-model-00 


Abstract 

   This document describes a YANG data model for SUPA (Simplified Use 
   of Policy Abstractions) ECA (Event-Condition-Action) policies 
   using policy abstractions defined in [I-D. strassner-supa-generic-
   policy-info-model]. The EPDM (ECA policy data model) is refined 
   from SGPIM and EPRIM to be applied to deliver various management 
   policies for controlling managed entities throughout the service 
   development and deployment lifecycle. The core data model could be 
   augmented by additional YANG data modules modeling and configuring 
   policy-related protocols and functions. Reusability as the major 
   advantage of this approach can be realized by metadata. The policy 
   data model described in this document provides common building 
   blocks for such extensions. 

 

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 

 
 
 
Chen, et al. 	       Expires January 2, 2016                [Page 1] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

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

   This Internet-Draft will expire on January 02,2016. 

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 .................................................3 
   2. Conventions used in this document ............................4 
      2.1. Tree Diagrams ...........................................4 
   3. SUPA Policy Modules Top Level Design .........................5 
      3.1. ECA Policy Data Model Design ............................6 
         3.1.1. supa-ECA-policy-rule sub class .....................6 
         3.1.2. supa-ECA-component sub class .......................7 
      3.2. supa-policy-statement Design for ECA policy data model ..7 
         3.2.1. supa-encoded-clause sub class ......................8 
         3.2.2. supa-boolean-clause sub class ......................8 
      3.3. supa-policy-term class ..................................9 
   4. Abstract ECA Policy Data Model Hierarchy ....................10 
   5. SUPA ECA Policy Data Model in YANG Module ...................12 
   6. Security Considerations .....................................18 
   7. IANA Considerations .........................................18 
   8. Contributor List ............................................18 
   9. Acknowledgments .............................................18 
   10. References .................................................19 
      10.1. Normative References ..................................19 
      10.2. Informative References ................................19 
    



 
 
Chen, et al.	       Expires January 2, 2016                [Page 2] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

1. Introduction 

   As defined in [I-D. strassner-supa-generic-policy-info-model], 
   policies either be used in a stand-alone policy rule or aggregated 
   into policy composite to perform more elaborate functions. The 
   SUPA policy is tree-structured and can be embedded into hierarchal 
   model.    

   In SUPA framework, 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. Note that, the 
   information model is independent of data repository, data 
   definition language, query language, implementation language, and 
   protocol. While the ECA policy has to be defined with data 
   repository, data definition language, query language, 
   implementation language, and protocol.  

   In this way, an ECA policy data model defines: 

   -An event or a set of events that trigger the evaluation of policy: 
   This is the trigger for the service management application to 
   evaluate if a policy needs to be applied. For example a user 
   action to provision a new VPN service can be an event. 

   -A set of conditions that need to be satisfied for the policy to 
   be applicable: This enables service management to select the right 
   policy by validating the conditions against the current network 
   state.  

   -A set of actions that should be triggered as part of the policy 
   execution: This enables the service management to provision the 
   service. 

   This document introduces YANG [RFC6020] [RFC6021] data models for 
   SUPA configuration. Such models can facilitate the standardization 
   for the interface of SUPA, as they are compatible to a variety of 
   protocols such as NETCONF [RFC6241] and [RESTCONF]. Please note 
   that in the context of SUPA, the term "application" refers to an 
   operational and management applications employed, and possibly 
   implemented, by an operator.  

   With respect to the scope, defining an information model for the 
   policy exchange between the policy manager and policy agent and a 
   corresponding data model based on yang to support specific DDC 
   service use case is initial goal. The protocol specific aspects 
   are deferred to respective implementations. Also certain 

 
 
Chen, et al.	       Expires January 2, 2016                [Page 3] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

   foundational concepts of the model are intentionally left open to 
   enable future extension.  

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. 

2.1. Tree Diagrams 

   A simplified graphical representation of the data model is used in 
   this document.  The meaning of the symbols in these diagrams is as 
   follows: 

   -Each node is printed as: 

        <status> <flags> <name> <opts> <type> 

        <status> is one of: 
          +  for current 
          x  for deprecated 
          o  for obsolete 
    

        <flags> is one of: 
            rw for Read/Write 
            ro for ReadOnly 
            -x for rpcs (remote procedure calls) 
            -n for notifications 
 
        <name> is the name of the node 

   -If the node is augmented into the tree from another module, its 
   name is printed as <prefix>:<name>. 

        <opts> is one of: 
          ?  for an optional leaf or choice 
          !  for a presence container 
          *  for a leaf-list or list 
 
             [<keys>] for the keys of a particular list 

          Figure 1: Symbols Used in Diagrams in this Document  
 
 
Chen, et al.   	       Expires January 2, 2016                [Page 4] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

3. SUPA Policy Modules Top Level Design 

   In this section, a policy data model is defined with SGPIM to 
   specify the top level sub-class. The SUPA policy is constructed 
   hierarchically with possible extension at each leaf node. 
   According to SGPIM framework, a supa-policy MUST have at least one 
   supa-policy-statement that is used to define the content of the 
   policy.  

   As shown in figure 2, the top level design policy data model is: 

   -supa-policy:          the root of the SPGIM model 

   -supa-policy-atomic:    a Policy that can be used in a stand-alone 
   manner 

   -supa-policy-composite: used to build hierarchies of Policies 

   -supa-policy-statement: used to define the content of a supa-
   policy 

   -supa-policy-term:      used to define variables, operators, and 
   values in a supa-policy-statement 

   -supa-policy-target:    the managed object that a supa-policy 
   monitors and/or controls the state of 

   -supa-policy-metadata:  specifies descriptive and/or prescriptive 
   information about a supa-policy object 

   +--rw supa-policy 
      | .... 
      +--rw supa-policy-atomic 
      |  | .... 
      +--rw supa-policy-composite 
      |  | .... 
      +--rw supa-policy-statement 
      |  | .... 
      +--rw supa-policy-target?            string 
      +--rw supa-policy-term 
      |  | .... 
      +--rw supa-policy-metadata?  
         | ....         
 
          Figure 2: Top level design of SUPA policy data model 


 
 
Chen, et al.           Expires January 2, 2016                [Page 5] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

3.1. ECA Policy Data Model Design 

   A supa-ECA-policy-rule, is a subclasses of the supa-policy-atomic 
   class. Therefore, it can be used as part of a hierarchy of 
   Policies or in a stand-alone manner. The EPRIM specializes the 
   supa-policy-atomic class to create a supa-ECA-policy-rule; it also 
   specializes the supa-policy class to create a supa-ECA-component, 
   and the supa-policy-statement to create a supa-boolean-clause. The 
   supa-ECA-policy-rule uses the rest of the SGPIM infrastructure to 
   define a complete Policy model according to ECA semantics. 

      +--rw supa-policy-atomic 
         +--rw supa-ECA-policy-rule 
         |  | .... 
         +--rw supa-ECA-component 
         |  | .... 
 
   Figure 3: The snippet of supa policy atomic with ECA policy rule 

   -A supa-ECA-policy-rule is defined as a subclass of the SGPIM 
   supa-policy-atomic class. A supa-policy-atomic has event, 
   condition, and action clauses; each of these is created by either 
   a supa-boolean-clause or a supa-encoded-clause. 

   -A supa-ECA-component defines supa-event, supa-condition, and 
   supa-action objects that are used to create the event, condition, 
   and action clauses of a supa-ECA-policy-rule. 

3.1.1. supa-ECA-policy-rule sub class 

   Similar to supa-policy class, the composite pattern is applied to 
   the supa-ECA-policy-rule class, enabling it to be used as either a 
   stand-alone policy rule or as a hierarchy of policy rules. 

         +--rw supa-ECA-policy-rule 
            +--rw supa-ECA-policy-rule-atomic 
            |  | .... 
            +--rw supa-ECA-policy-rule-composite 
               | .... 
 
   Figure 4: The snippet of supa-ECA-policy-rule sub class 

   -A supa-ECA-policy-rule-atomic class represents a SUPA ECA Policy 
   Rule that can operate as a single, stand-alone, manageable object. 
   Put another way, a supa-ECA-policy-rule-atomic object can NOT be 
   modeled as a set of hierarchical supa-ECA-policy-rule objects; if 

 
 
Chen, et al.           Expires January 2, 2016                [Page 6] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

   this is required, then a supa-ECA-policy-rule-composite object 
   must be used. 

   -A supa-ECA-policy-rule-composite class represents a SUPA ECA 
   Policy Rule as a hierarchy of Policy objects, where the hierarchy 
   contains instances of a supa-ECA-policy-rule-atomic and/or supa-
   ECA-policy-rule-composite object. 

3.1.2. supa-ECA-component sub class 

   The principal subclasses of supa-policy-term that are defined in 
   this version of this document are supa-policy-event, supa-policy-
   condition, and supa-policy-action. More details will be in next 
   version. The snippet of supa-ECA-component sub class is shown in 
   figure 5. 

         +--rw supa-ECA-component 
            +--rw has-policy-events?       boolean 
            +--rw has-policy-conditions?   boolean 
            +--rw has-policy-actions?      Boolean 
 
          Figure 5: The snippet of supa-ECA-component objects 

3.2. supa-policy-statement Design for ECA policy data model 

   This is a mandatory abstract class that separates the 
   representation of a supa-policy from its implementation. This 
   abstraction is missing in [RFC3060], [RFC3460]. As shown in figure 
   6, there are two principal subclasses of supa-policy-statement: 

   -supa-encoded-clause, which is a mechanism to directly encode the 
   content of the supa-policy-statement into a set of attributes; 
   this is described in more detail in Section 3.2.1. 

   -supa-boolean-clause, which defines a supa-policy-statement as a 
   set of one or more clauses; multiple clauses may be combined with 
   Boolean AND and OR operators. This defines a supa-policy as a 
   completely reusable set of supa-policy objects that are structured 
   in an ECA form, and is described in more detail in Section 3.2.2. 







 
 
Chen, et al.           Expires January 2, 2016                [Page 7] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

      +--rw supa-policy-statement 
         +--rw supa-encoded-clause 
         |  | .... 
         +--rw supa-boolean-clause 
            +--rw supa-boolean-clause-atomic 
            |  | .... 
 
             Figure 6: The snippet of supa-policy-statement 

3.2.1. supa-encoded-clause sub class 

   This is a mandatory concrete class that specializes (i.e., is a 
   subclass of) a supa-policy-statement. It defines a generalized 
   extension mechanism for representing supa-policy-statement that 
   have not been modeled with other supa-policy objects. Rather, the 
   Policy Clause is directly encoded into the attributes of the supa-
   encoded-clause. 

   -supa-clause-content defines the content of this encoded clause of 
   this clause. It works with another attribute of the supa-encoded-
   clause class, called supa-clause-format, 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. 

   -supa-clause-format defines the format of this encoded clause. It 
   works with another attribute of the supa-encoded-clause class, 
   called supa-clause-content, which defines the content (i.e., the 
   value) of the encoded clause. 

         +--rw supa-encoded-clause 
         |  +--rw supa-clause-content?   string 
         |  +--rw supa-clause-format?    String 
 
              Figure 7: The snippet of supa-encoded-clause 

3.2.2. supa-boolean-clause sub class 

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

            {PolicyVariable, PolicyOperator, PolicyValue} 

   The composite pattern is used in order to construct complex 
   Boolean clauses from a set of supa-boolean-clause objects. This is 
   why supa-boolean-clause is defined to be abstract - only instances 
   of the supa-boolean-clause-atomic and/or supa-boolean-clause-
 
 
Chen, et al.           Expires January 2, 2016                [Page 8] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

   composite classes can be used to construct a supa-boolean-clause. 
   As shown in figure 8, it aggregates supa-policy-variable, supa-
   policy-operator, and supa-policy-value objects to form a complete 
   supa-boolean-clause. 

         +--rw supa-boolean-clause 
            +--rw supa-boolean-clause-atomic 
               +--rw supa-policy-variable?   string 
               +--rw supa-policy-operator?   enumeration 
               +--rw supa-policy-value?      uint32 
 
              Figure 8: The snippet of supa-boolean-clause 

3.3. supa-policy-term class 

   The principal subclasses of supa-policy-term that are defined in 
   this version of this document are supa-policy-event, supa-policy-
   condition, and supa-policy-action. 

   -The value of a supa-policy-variable is typically compared to the 
   value of a supa-policy-value using the type of operator defined in 
   a supa-policy-operator. 

   -supa-policy-operator defines class for modeling different types 
   of operators that are used in a supa-policy-statement. 

   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 
    

   -The supa-policy-value class is a mandatory abstract class for 
   modeling different types of values and constants that occur in a 
   supa-policy-statement. 


 
 
Chen, et al.           Expires January 2, 2016                [Page 9] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

      +--rw supa-policy-term 
         +--rw supa-policy-variable?   string 
         +--rw supa-policy-operator?   enumeration 
         +--rw supa-policy-value?      uint32 
 
               Figure 9: The snippet of supa-policy-term 

4. Abstract ECA Policy Data Model Hierarchy 

   Figure 10 shows the structure of abstract SUPA ECA policy data 
   model.  



































 
 
Chen, et al.           Expires January 2, 2016               [Page 10] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

module: ietf-supa-policy 
   +--rw supa-policy 
      +--rw supa-policy-name?              string 
      +--rw supa-policy-type?              enumeration 
      +--rw applicable-service-type?       enumeration 
      +--rw supa-policy-priority?          uint8 
      +--rw supa-policy-validity-period 
      |  +--rw start?         yang:date-and-time 
      |  +--rw end?           yang:date-and-time 
      |  +--rw duration?      uint32 
      |  +--rw periodicity?   enumeration 
      +--rw supa-policy-atomic 
      |  +--rw supa-ECA-policy-rule 
      |  |  +--rw policy-rule-deploy-status?        enumeration 
      |  |  +--rw policy-rule-exec-status?          enumeration 
      |  |  +--rw supa-ECA-policy-rule-atomic 
      |  |  +--rw supa-ECA-policy-rule-composite 
      |  +--rw supa-ECA-component 
      |     +--rw has-policy-events?       boolean 
      |     +--rw has-policy-conditions?   boolean 
      |     +--rw has-policy-actions?      boolean 
      +--rw supa-policy-composite 
      +--rw supa-policy-statement 
      |  +--rw supa-encoded-clause 
      |  |  +--rw supa-clause-content?   string 
      |  |  +--rw supa-clause-format?    string 
      |  +--rw supa-boolean-clause 
      |     +--rw supa-boolean-clause-atomic 
      |        +--rw supa-policy-variable?   string 
      |        +--rw supa-policy-operator?   enumeration 
      |        +--rw supa-policy-value?      uint32 
      +--rw supa-policy-target?            string 
      +--rw supa-policy-term 
      |  +--rw supa-policy-variable?   string 
      |  +--rw supa-policy-operator?   enumeration 
      |  +--rw supa-policy-value?      uint32 
      +--rw supa-policy-metadata?          uint32 
 
     Figure 10: The structure of abstract SUPA ECA policy data model 

    






 
 
Chen, et al.           Expires January 2, 2016               [Page 11] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

 
5. SUPA ECA Policy Data Model in YANG Module 

    
   <CODE BEGINS> 
   module ietf-supa-policy { 
     namespace "urn:ietf:params:xml:ns:yang:ietf-supa-policy"; 
     // replace with IANA namespace when assigned 
     prefix policy; 
    
     import ietf-inet-types { 
       prefix inet; 
     } 
    
     organization "IETF"; 
     contact 
       "Editor: Maoke Chen"; 
    
     description 
       "This YANG module defines a component that describing 
        the ECA policy data model refining from SGPIM and EPRIM. 
    
        Terms and Acronyms 
          
     revision 2015-07-02 { 
       description 
       "Initial revision."; 
       reference 
           " ECA Policy YANG Data Model refining from SGPIM and 
        EPRIM"; 
     } 
    
   container supa-policy{ 
     description 
       "Top level class of policy  model that can be integrated into 
        another model"; 
     leaf supa-policy-name { 
           type string; 
           description 
             "The name of policy"; 
         } 
     leaf supa-policy-type { 
           type enumeration { 
         enum local { 
           description "local";        
         } 
         enum global { 
 
 
Chen, et al.           Expires January 2, 2016               [Page 12] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

           description "globe";        
             } 
           } 
       } 
     leaf applicable-service-type { 
           type enumeration { 
         enum local { 
           description "local";        
         } 
         enum globe { 
           description "globe";        
         } 
           } 
       } 
      
     leaf supa-policy-priority { 
       type uint8; 
     } 
    
     container supa-policy-validity-period { 
       description 
       "The validity time period of the policy will define the 
        start time and end time of the policy on a daily or monthly 
        fashion periodicity. "; 
       leaf start { 
         type yang:date-and-time; 
       }  
       leaf end { 
         type yang:date-and-time; 
       } 
       leaf duration { 
         type uint32; 
       } 
       leaf periodicity { 
         type enumeration { 
           enum daily { 
             description "daily";        
           } 
           enum monthly { 
             description "monthly";        
           } 
         } 
           } 
     } 
    
     container supa-policy-atomic { 
       description 
 
 
Chen, et al.           Expires January 2, 2016               [Page 13] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

       "A sub class of policy which define a Policy that can be 
        used in a stand-alone manner"; 
       container supa-ECA-policy-rule { 
         description "The event-condition-action policy rule"; 
          
         leaf policy-rule-deploy-status { 
           type enumeration { 
             enum 0{ 
               description "undefined";        
             } 
             enum 1{ 
               description "deployed and enabled";        
             } 
             enum 2{ 
               description "deployed and in test";        
             } 
             enum 3{ 
               description "deployed but not enabled";        
             } 
             enum 4{ 
               description "ready to be deployed";        
             } 
             enum 5{ 
               description "not deployed";        
             } 
           } 
         } 
    
         leaf policy-rule-exec-status { 
           type enumeration { 
             enum 0{ 
               description "undefined";        
             } 
             enum 1{ 
               description "executed and SUCEEDED (operational mode)";       
             } 
             enum 2{ 
               description "executed and FAILED (operational mode)";        
             } 
             enum 3{ 
               description "currently executing (operational mode)";        
             } 
             enum 4{ 
               description "executed and SUCEEDED (test mode)";        
             } 
             enum 5{ 
               description "executed and FAILED (test mode)";        
 
 
Chen, et al.           Expires January 2, 2016               [Page 14] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

             } 
             enum 6{ 
               description "currently executing (test mode)";        
             } 
           } 
         } 
          
         container supa-ECA-policy-rule-atomic { 
           description "A SUPAECAPolicyRuleAtomic class  
           represents a SUPA ECA Policy Rule that can operate as 
           a single, stand-alone, manageable object."; 
         } 
         container supa-ECA-policy-rule-composite { 
           description "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."; 
         } 
       } 
       container supa-ECA-component{ 
         leaf has-policy-events { 
           type boolean; 
           description 
           "An event or a set of events that trigger the evaluation 
         of policy: This is the trigger for the service management 
         application to evaluate if a policy needs to be applied.  
         For example a user action to provision a new VPN service  
         can be an event."; 
         } 
         leaf has-policy-conditions { 
           type boolean; 
           description 
            "A set of conditions that need to be satisfied for the  
         policy to be applicable: This enables service management  
         to select the right policy by validating the conditions  
         against the current network state."; 
         } 
         leaf has-policy-actions { 
           type boolean; 
           description 
            "A set of actions that should be triggered as part of the 
         policy execution: This enables the service management to 
         provision the service."; 
         } 
       } 
 
 
Chen, et al.           Expires January 2, 2016               [Page 15] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

     } 
      
     container supa-policy-composite { 
       description "SUPA Policy Composite is used to build 
       hierarchies of Policies"; 
     } 
      
     container supa-policy-statement { 
       description 
         "A SUPA Policy Statement 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 
       one or more managed objects."; 
          
       container supa-encoded-clause{ 
         description "SUPAEncodedClause, which is a mechanism to 
         directly encode the content of the SUPAPolicyStatement 
         into a set of attributes"; 
            
         leaf supa-clause-content { 
           description "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."; 
            
           type string; 
         } 
         leaf supa-clause-format { 
           description "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."; 
            
           type string; 
         } 
       } 
       container supa-boolean-clause{ 
         description "SUPABooleanClause, which defines a  
         SUPAPolicyStatement as a set of one or more clauses;  
 
 
Chen, et al.           Expires January 2, 2016               [Page 16] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

         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"; 
            
         container supa-boolean-clause-atomic { 
           description "This is a mandatory abstract class that 
           represents a SUPABooleanClause that can operate as a  
           single, stand-alone, manageable object."; 
            
           leaf supa-policy-variable { 
             type string; 
           description ""; 
           } 
           leaf supa-policy-operator { 
             type enumeration ; 
             description ""; 
           } 
           leaf supa-policy-value { 
             type int32; 
             description "";   
           } 
         } 
       } 
     } 
    
     leaf supa-policy-target { 
       description "SUPAPolicyTarget is an abstract class that  
       defines a set of managed objects that may be affected by the  
       actions of a SUPAPolicyStatement."; 
        
       type string; 
     } 
     container supa-policy-term { 
       description "The principal subclasses of SUPAPolicyTerm that 
       are defined in this version of this document are  
       SUPAPolicyVariable, SUPAPolicyOperator, and SUPAPolicyValue.  
       These terms enable generic statements to be created from a  
       set of reusable terms."; 
    
       leaf supa-policy-variable { 
         type string; 
         description ""; 
       } 
       leaf supa-policy-operator { 
         type enumeration ; 
         description ""; 
 
 
Chen, et al.           Expires January 2, 2016               [Page 17] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

       } 
       leaf supa-policy-value { 
         type int32; 
         description ""; 
       } 
     } 
      
     leaf supa-policy-metadata { 
       type uint32; 
    } 
   } 
   }<CODE ENDS> 
    
    
6. Security Considerations 

   TBD 

    

7. IANA Considerations 

   This document has no actions for IANA.  

    

8. Contributor List 

   Andy Bierman 

   YumaWorks, Inc. 

   Email: andy@yumaworks.com 

    

9. Acknowledgments 

   This document has benefited from reviews, suggestions, comments 
   and proposed text provided by the following members, listed in 
   alphabetical order: Juergen Schoenwaelder, John, Strassner and 
   Yiyong Zha. 






 
 
Chen, et al.           Expires January 2, 2016               [Page 18] 

Internet-Draft       SUPA ECA Policy Data Model              July 2015 
    

10. References 

10.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

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

   [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.          
             Xiao, "Overview and Principles of Internet Traffic            
             Engineering", RFC 3272, May 2002. 

10.2. Informative References 

   [I-D. strassner-supa-generic-policy-info-model] John Strassner, 
   "Generic Policy Information Model for Simplified Use of Policy 
   Abstractions (SUPA)", draft-strassner-supa-generic-policy-info-
   model-01 (work in progress), May 2015. 

   [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 
   "RESTCONF Protocol", draft-ietf-netconf-restconf (work in 
   progress), July 2014. 

   [POLICY MODEL] Z. Wang, L. Dunbar, Q. Wu, "Network Policy YANG 
   Data Model" draft-wang-netmod-yang-policy-dm, January 2015. 

Authors' Addresses 

   Maoke Chen
   BBIX, Inc.
   Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1
   Minato-ku, Tokyo, 105-7310, Japan
   Email: maoke@bbix.net

   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, Sur-3 building, 3rd floor
   Madrid  28050, Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://people.tid.es/LuisM.Contreras/

   Masaki Fukushima 
   KDDI R&D Labs. Inc. 
   2-1-15 Ohara, Fujimino, Saitama, Japan. 356-8502 
   Email: fukusima@kddilabs.jp 
 









 
 
Chen, et al.           Expires January 2, 2016               [Page 19] 


PAFTECH AB 2003-20262026-04-24 06:45:57