Network Working Group M. Chen Internet Draft BBIX, Inc. Intended status: Standard Track L.Contreras Expires: January 22, 2016 Telefonica I+D M. Fukushima KDDI R&D Labs. Inc. July 22, 2015 ECA Policy YANG Data Model draft-chen-supa-eca-data-model-01 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." Chen, et al. Expires January 22,2016 [Page 1] Internet-Draft SUPA ECA Policy Data Model July 2015 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 January 22,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. Data Model Example ..........................................18 7. Security Considerations .....................................21 8. IANA Considerations .........................................22 9. Contributor List ............................................22 10. Acknowledgments ............................................22 11. References .................................................22 11.1. Normative References ..................................22 11.2. Informative References ................................22 Chen, et al. Expires January 22,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. - 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 22,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: is one of: + for current x for deprecated o for obsolete is one of: rw for Read/Write ro for ReadOnly -x for rpcs (remote procedure calls) -n for notifications is the name of the node -If the node is augmented into the tree from another module, its name is printed as :. is one of: ? for an optional leaf or choice ! for a presence container * for a leaf-list or list [] for the keys of a particular list Figure 1: Symbols Used in Diagrams in this Document Chen, et al. Expires January 22,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 22,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 22,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 22,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 22,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 22,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 22,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 22,2016 [Page 11] Internet-Draft SUPA ECA Policy Data Model July 2015 5. SUPA ECA Policy Data Model in YANG Module 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-22 { 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 22,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 22,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 22,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 22,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 22,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 "The definition of the variable"; } leaf supa-policy-operator { type enumeration { enum 0 { description "Equal to"; } enum 1 { description "Larger than"; } enum 2 { description "Less than"; } } } leaf supa-policy-value { type uint32; description "Vaule of the variable"; } } } } 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 Chen, et al. Expires January 22,2016 [Page 17] Internet-Draft SUPA ECA Policy Data Model July 2015 set of reusable terms."; leaf supa-policy-variable { type string; description "The definition of the variable"; } leaf supa-policy-operator { type enumeration { enum 0 { description "Equal to"; } enum 1 { description "Larger than"; } enum 2 { description "Less than"; } } } leaf supa-policy-value { type uint32; description "The value of the variable"; } } leaf supa-policy-metadata { type uint32; } } } 6. Data Model Example This section will provide one example to show how this ECA policy data model can be mapped into real configuration. For a service flow policy, if a flow matches certain conditions, then some actions to this flow will be performed. As shown below: Chen, et al. Expires January 22,2016 [Page 18] Internet-Draft SUPA ECA Policy Data Model July 2015 +--supa-policy-composite (flow-poliy-entry) +--supa-ECApolicy-rule-atomic (flow-filter-condition, flow-classifier-action) +--for each filter-condition node that is not an identityref +--supa-boolean-clause-atomic (flow-filter- condition) +--supa-policy-variable (source-ip-address variable) +--supa-policy-operator (typically "MATCH" default) +--supa-policy-value (condition value e.g. "10.111.10.1") +--supa-boolean-clause-atomic (flow-filter- condition) +--supa-policy-variable (destnation-ip-address variable) +--supa-policy-operator (typically "MATCH" default) +--supa-policy-value (condition value e.g. "10.112.10.1") +--supa-boolean-clause-atomic (flow-filter- condition) +--supa-policy-variable (source-port variable) +--supa-policy-operator (typically "MATCH" default) +--supa-policy-value (condition value e.g. "8080") +--supa-boolean-clause-atomic (flow-filter- condition) +--supa-policy-variable (destnation-port variable) +--supa-policy-operator (typically "MATCH" default) +--supa-policy-value (condition value e.g. "8090") +--for each action node that is not an identityref +--supa-boolean-clause-Composite +--supa-boolean-clause-atomic +--supa-policy-action-name (action name e.g. "redirect") +--supa-policy-action-variable (action value "interface") +--supa-policy-action-value (action value "Gre-Tunnel-IF-10") +--supa-policy-Composite (child-policy-) Chen, et al. Expires January 22,2016 [Page 19] Internet-Draft SUPA ECA Policy Data Model July 2015 Actually, the ECA policy data model only specify the type of each node, e.g., the type of the supa-policy-variable is string, and the real value of a "condition" clause can be source-ip-address. After filling up all the tags in the data model, the configuration related data model denotes to certain policy configuration which is dependent on the use case. Then the data model is used to guide the XML instance as shown below: Chen, et al. Expires January 22,2016 [Page 20] Internet-Draft SUPA ECA Policy Data Model July 2015 Match10.111.10.1< /SourceIP> Match8080 Match10.112.10.2 Match8090 redirect node dc1 interface Gre-Tunnel-IF-1 redirect node pop1 interface Gre-Tunnel-IF-2 redirect node pop2 interface Gre-Tunnel-IF-3 7. Security Considerations TBD Chen, et al. Expires January 22,2016 [Page 21] Internet-Draft SUPA ECA Policy Data Model July 2015 8. IANA Considerations This document has no actions for IANA. 9. Contributor List Andy Bierman YumaWorks, Inc. Email: andy@yumaworks.com 10. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Juergen Schoenwaelder, Yiyong Zha. 11. References 11.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. 11.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. Chen, et al. Expires January 22,2016 [Page 22] Internet-Draft SUPA ECA Policy Data Model July 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 22,2016 [Page 23]