wdiff rfc8328.alt-original rfc8328.txt

Network Working Group
Independent Submission W. Liu
Internet-Draft
Request for Comments: 8328 Huawei Technologies
Intended status:
Category: Informational C. Xie
Expires: March 31, 2018
ISSN: 2070-1721 China Telecom
J. Strassner
G. Karagiannis
Huawei Technologies
M. Klyus
NetCracker

J. Bi
Tsinghua University
Y. Cheng
China Unicom
D. Zhang
Huawei Technologies
September 27, 2017

SUPA Policy-based
February 2018

Policy-Based Management Framework
draft-liu-policy-based-management-framework-00 for the Simplified Use of Policy
Abstractions (SUPA)

Abstract

The Simplified Use of Policy Abstractions (SUPA) policy-based
management framework defines base YANG data models to encode policy, which policy.
These models point to device-, technology-, and service-specific YANG
data models developed elsewhere. Policy rules within an operator's
environment can be used to express high-level, possibly network-wide network-wide,
policies to a network management function (within a controller, an
orchestrator, or a network element). The network management function
can then control the configuration and/or monitoring of network
elements and services. This document describes the SUPA basic
framework, its elements elements, and interfaces.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not candidates for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Standard;
see Section 2 of RFC 7841.

Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2018.
https://www.rfc-editor.org/info/rfc8328.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations and Definitions . . . . . . . . . . . . . . 4
3. Framework for Generic Policy-based Policy-Based Management . . . . . . . . 4 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 10
3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 10
3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12
6. Contributors References . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . 12
8. References . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . 13
Contributors . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 14

1. Introduction

Traffic flows over increasingly complex enterprise and service
provider networks become are becoming more and more important. Meanwhile,
the rapid growth of the this variety makes the task of network operations
and management applications deploying new services much more
difficult. Moreover, network operators want to deploy new services
quickly and efficiently. Two possible mechanisms for dealing with
this growing difficulty are 1) the use of software abstractions to
simplify the design and configuration of monitoring and control operations,
operations and 2) the use of programmatic control over the
configuration and operation of such networks. Policy-based
management can be used to combine these two mechanisms into an
extensible framework.

Policy

There is a set of policy rules within an operator's environment are a set of rules that
define
defines how services are designed, delivered, and operated.

The SUPA (Simplified Use of Policy Abstractions) data model
represents high-
level, a high-level, possibly network-wide policy, which can be
input to a network management function (within a controller, an
orchestrator, or a network element).The element). The network management function
can then control the configuration and/or monitoring of network
elements and services according to such policies.

SUPA defines a generic policy information model Generic Policy Information Model (GPIM) [I-D.ietf-
supa-generic-policy-info-model] [SUPA-INFO]
for use in network operations and management applications. The GPIM
defines concepts and terminology needed by policy management
independent of the form and content of the policy rule. The Event-Condition-Action Event-
Condition-Action (ECA) Policy Rule Information Model (EPRIM) [I-D.ietf-supa-generic-policyinfo-model]
[SUPA-INFO] extends the GPIM by defining how to build policy rules
according to the event-condition-action ECA paradigm.

Both the GPIM and the EPRIM are targeted at controlling the
configuration and monitoring of network elements throughout the
service development and deployment lifecycle. life cycle. The GPIM and the
EPRIM can both be translated into corresponding YANG [RFC6020][RFC6020bis] [RFC6020]
[RFC7950] modules that define policy concepts, terminology, and rules
in a generic and interoperable manner; additional YANG modules may
also be derived from the GPIM and/or EPRIM to manage specific
functions.

The key benefit of policy management is that it enables different
network elements and services to be instructed to behave the same
way, even if they are programmed differently. Management
applications will benefit from using policy rules that enable
scalable and consistent programmatic control over the configuration
and monitoring of network elements and services.

Some typical and useful instances, instances for authors to understand the
applicability of SUPA, such as SNMP blocking upon load of link
reaching a threshold, threshold and virtual maching matching migration upon the changinng changing
of user location, are written described in [I-D.cheng-supa-applicability]. [SUPA-APP].

2. Terminology

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2.2. Abbreviations and Definitions

SUPA: The Simplified Use of Policy Abstractions, Abstractions is the working group
name, which a policy-based
management framework that defines a data model, model to be used to
represent high-level, possibly network-wide policies, which policies. This data
model can be input to a network management function (within a
controller, an orchestrator, or a network element).

YANG: an An acronym for "Yet Another Next Generation". YANG is a data
modeling language used to model configuration and state data
manipulated by the Network Configuration Protocol (NETCONF), NETCONF
remote procedure calls, and NETCONF notifications.[RFC6020] notifications [RFC6020]

ECA: Event-Condition-Action, Event-Condition-Action is a short-cut shortcut for referring to the
structure of active rules in event driven event-driven architecture and active
database systems.

EMS: An Element Management System, System is software used to monitor and
control network elements (devices) in telecommunications.

NMS: A Network Management System, System is a set of hardware and/or software
tools that allow an IT professional to supervise the individual
components of a network within a larger network management framework.

OSS: An Operations/Operational Support System, are System is a computer systems system
used by telecommunications service providers to manage their networks
(e.g., telephone networks).

BSS: A Business Support Systems, are System is used to support various end-to-end
telecommunication services.

GPIM: A Generic Policy Information Model, which Model defines concepts and
terminology needed by policy management independent of the form and
content of the policy rule.

EPRIM: An ECA Policy Rule Information Model, which Model extends the GPIM by
defining how to build policy rules according to the event-condition-
action ECA paradigm.

GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data-
model], [SUPA-DATA] are created from the
GPIM. These YANG data model policies are used to control the
configuration of network elements that model the service(s) to be
managed. The relationship of between the information model (IM) and DM
data model (DM) can be founded in [RFC3444].

Declarative Policy: policies Policies that specify the goals to be achieved
but not how to achieve those goals (also called "intent-based"
policies). Please note that declarative policies are out of scope
for the initial phase of SUPA.

3. Framework for Generic Policy-based Policy-Based Management

This section briefly describes the design and operation of the SUPA
policy-based management framework.

3.1. Overview

Figure 1 shows a simplified functional architecture of how SUPA is
used to define policies for creating snippets of network element configuration
snippets. (Note from Editor: a "snippet" is a small piece of
information (e.g., part of a sentence that was cut out).)
configurations. SUPA uses the GPIM to define a consensual vocabulary
that different actors can use to interact with network elements and
services. The EPRIM defines a generic structure for imperative
policies. The GPIM, and/
or and/or the combination of the GPIM and the
EPRIM, is converted to generic YANG data modules.

In one possible approach (shown with asterisks in Figure 1), SUPA
Generic Policy and SUPA ECA Policy YANG data modules together with the
Resource and Service YANG data models specified in the IETF (which
define the specific elements that will be controlled by policies) are
used by the Service Interface Logic. This Service Interface Logic
creates appropriate input mechanisms for the operator to define
policies (e.g., a web form or a script) for creating and managing the
network configuration. The operator interacts with the interface,
and the policies input by operators are then translated to into
configuration snippets.

Note that the Resource and Service YANG data models may not exist.
In this case, the SUPA generic policy YANG data modules serve as an
extensible basis to develop new YANG data models for the Service
Interface Logic Logic. This transfers the work specified by the Resource
and Service YANG data models specified in the IETF into the Service
Interface Logic.

+---------------------+
+----------+ \| SUPA |
| IETF |---+----+ Information Models |
+----------+ | /| GPIM and EPRIM |
| +---------+-----------+
Assignments | | Defines Policy Concepts
and Manage Managed | \|/
Content | +---------+-----------+
| \| SUPA Generic |
+----+ & ECA Policy |
/| YANG Data modules |
+---------+-----------+
* Possible Approach
+-----------------------------*-----------------------------+
| Management System * |
| \*/ |
| Fills +---------+---------+ +-------------+ |
| +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+
| |Operator|--------+ Logic +--|Service YANG |----|IETF|
| +--------+ Runs /| (locally defined |\ | Data Models data models |\ | +----+
| scripts |forms, scripts,...)| +-------------+ |
| +---------+---------+ |
| \|/ |
| +-------+--------+ |
| | Local Devices | |
| | and Management | |
| | Systems | |
| +----------------+ |
+-----------------------------------------------------------+

Figure 1: SUPA Framework

Figure 1 is exemplary. shows the SUPA Framework at a high level of abstraction.
The Operator operator actor can interact with SUPA in other ways not shown in
Figure 1. In addition, other actors (e.g., an application developer)
that can interact with SUPA are not shown for simplicity.

The EPRIM defines an ECA policy as an example of imperative policies.
An ECA policy rule is activated when its event clause is true; the
condition clause is then evaluated and, if true, signals the
execution of one or more actions in the action clause. This type of
policy explicitly defines the current and desired states of the
system being managed. Imperative policy rules require additional
management functions, which are explained in section 3.2 below. Section 3.2.

Figure 2 shows how the SUPA Policy Model is used to create policy
data models step by step step-by-step and how the policy rules are used to
communicate among various network management functions located on
different layers.

The Generic Policy Information Model (GPIM) GPIM is used to construct policies. The GPIM defines generic
policy concepts, concepts as well as two types of policies: ECA policy rules
and declarative policy statements.

A set of Generic Policy Data Models (GPDM) are then created from the
GPIM. These YANG data model policies are then used to control the
configuration of network elements that model the service(s) to be
managed.

Resource and Service YANG Data Models: models Models of the service as well
as physical and virtual network topology including the resource
attributes (e.g., data rate or latency of links) and operational
parameters needed to support service deployment over the network
topology.

| SUPA Policy Model
|
| +----------------------------------+
| | Generic Policy Information Model |
| +----------------------------------+
| D D
| D +-------------v-------------+
+----------------------+ | D | ECA Policy Rule |
| OSS/BSS/Orchestrator <--+ | D | Information Model |
+----------^-----------+ | | D +---------------------------+
C | | D D
C | | +----+D+------------------------+D+---+
C +-----+ D SUPA Policy Data Model D |
+----------v-----------+ | | ----v-----------------------+ D |
| EMS/NMS/Controller <--------+ | Generic Policy Data Model | D |
+----------^-----------+ | | ----------------------------+ D |
C +-----+ D D |
C | | | +---------v-----------------v--+ |
+----------v-----------+ | | | | ECA Policy Rule Data Model | |
| Network Element <--+ | | +------------------------------+ |
+----------------------+ | +-------------------------------------+
|
|

Figure 2: SUPA Policy Model Framework

In Figure 2:
Legend:
The double-headed arrow with Cs means communication; = "communication"
The arrow with Ds means derived from.

The components within this framework are: = "derived from"

Figure 2: SUPA Policy Model Framework
SUPA Policy Model: This model represents one or more policy modules
that contain the following entities:

Generic Policy Information Model: a A model for defining policy
rules that are independent of data repository, data definition,
query, implementation languages, language, and protocol. This model is
abstract and is used for design; it MUST be turned into a data
model for implementation.

Generic Policy Data Model: a A model of policy rules that are
dependent on data repository, data definition, query,
implementation languages, language, and protocol.

ECA Policy Rule Information Model (EPRIM): This model represents
a policy rule as a statement that consists of an event clause,
a condition clause, and an action clause. This type of Policy Rule policy
rule explicitly defines the current and desired states of the
system being managed. This model is abstract and is used for
design; it MUST be turned into a data model for implementation.

ECA Policy Rule Data Model: a A model of policy rules, derived from
EPRIM, while where each policy rule consists of an event clause, a
condition clause, and an action clause.

EMS/NMS/Controller: This represents one or more entities that are
able to control the operation and management of a network
infrastructure (e.g., a network topology that consists of Network Elements).
network elements).

Network Element (NE), which (NE): An element that can interact with the local
or remote EMS/NMS/Controller in order to exchange information,
such as configuration information, policy enforcement policy-enforcement
capabilities, and network status.

Relationship between

Relationships among Policy, Service Service, and Resource models can be are
illustrated by the figure below. in Figure 3.

+---------------+ +----------------+
| Policy | (1) | Service |
| |*******************| |
| ( SUPA ) |*******************| ( L3SM, ... ) |
+---------------+ +----------------+
** /*\
** *
** *
(2) ** * (3)
** *
** *
** *
+-------------------+
| Resource |
| |
| (Inventory, ... ) |
+-------------------+

Figure 3: Relationship between among Policy, Service Service, and Resource models Models

In Figure 3:

(1) The policy manages and can adjust service behavior as necessary
(1:1..n). In addition, data from resources and services are
used to select and/or modify policies during runtime.

(2) The policy manages and can adjust resource behavior as necessary
(1:1..n)
(1:1..n).

(3) resource Resource hosts service; changing resources may change service
behavior as necessary necessary.

Policies are used to control the management of resources and
services, while data from resources and services are used to select
and/or modify policies during runtime. More importantly, policies
can be used to manage how resources are allocated and assigned to
services. This enables a single policy to manage one or multiple
services and resources as well as their dependencies. The use of
(1:1..n) in point (1) and (2) below figure 3 above show that one policy rule is able
to manages manage and can adjust one or multiple services/resources. Line Lines
(1) and (2)
connecting (connecting policy to resource and policy to service service) are
the same, and line (3) connecting (connecting resource to service service) is different
as it's navigable only from resource to service.

3.2. Operation

SUPA can be used to define various types of policies, including
policies that affect services and/or the configuration of individual
network elements or groups of network elements. SUPA can be used by
a centralized and/or distributed set of entities for creating,
managing, interacting with, and retiring policy rules.

The SUPA scope is limited to policy information and data models.
SUPA does not define network resource data models or network service
data models; both are out of scope. Instead, SUPA makes use of
network resource data models defined by other WGs working groups or SDOs.
Standards Development Organizations (SDOs).

Declarative policies are out of scope for the initial phase of SUPA.

3.3. The GPIM and the EPRIM

The GPIM provides a common shared vocabulary for representing concepts that
are common to different types of policy, policies, but which are independent
of language, protocol, repository, and level of abstraction. Hence,
the GPIM defines concepts and vocabulary needed by policy management
systems independent of the form and content of the policy. The EPRIM
is a more specific model that refines the GPIM to specify policy
rules in an event-condition-action ECA form.

This enables different policies at different levels of abstraction to
form a continuum, where more abstract policies can be translated into
more concrete policies, policies and vice-versa. vice versa. For example, the information
model can be extended by generalizing concepts from an existing data
model into the GPIM; the GPIM extensions can then be used by other
data models.

3.4. Creation of Generic YANG Modules

An information model is abstract. As such, it cannot be directly
instantiated (i.e., objects cannot be created directly from it).
Therefore, both the GPIM and the combination of the GPIM and the
EPRIM,
EPRIM are translated to into generic YANG modules.

SUPA will provide guidelines for translating the GPIM (or the
combination of the GPIM and the EPRIM) into concrete YANG data models
that define how to manage and communicate policies between systems.
Multiple imperative policy YANG data models may be instantiated from
the GPIM (or the combination of the GPIM and the EPRIM). In
particular, SUPA will specify a set of YANG data models that will
consist of a base policy model for representing policy management
concepts independent of the type or structure of a policy, and as
well, policy; it will
also specify an extension for defining policy rules according to the
ECA
paradigm.(Note from Editor: paradigm. (Note: This means that policies can be defined using
the GPIM directly, or using the combination of the GPIM and the
EPRIM. If you use only the GPIM, you get a technology- and vendor-
independent information model that you are free to map to the data
model of your choice; note that the structure of a policy is NOT
defined. If you use the GPIM and the EPRIM, you get a technology-
and vendor-independent information model that defines policies as an
event-condition-action
ECA policy rule (i.e., imperative) rule.) imperative).)

The process of developing the GPIM, EPRIM and the derived/translated EPRIM, and the derived/
translated YANG data models is realized following the sequence shown
below. After completing this process and and, if the implementation of
the YANG data models requires it, the GPIM and EPRIM and the derived/
translated YANG data models are updated and synchronized.

(1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1')

Where, (1)=GPIM; (2)=EPRIM;

Where:
(1)=GPIM
(2)=EPRIM
(3)=YANG data models; (4)=
Implementation; (3')= update models
(4)=Implementation
(3')=update of YANG data models; models
(2')=update of
EPRIM; (1') = update EPRIM
(1')=update of GPIM

The YANG module derived from the GPIM contains concepts and
terminology for the common operation and administration of policy-
based systems, systems as well as an extensible structure for policy rules of
different paradigms. The YANG module derived from the EPRIM extends
the generic nature of the GPIM by representing policies using an
event-condition-action ECA
structure.

The above sequence allows for the addition of new, new model elements, as
well as the editing of existing model elements ones, in the GPIM and EPRIM. In
practice, the implementation sequence may be much simpler.
Specifically, it is unlikely that the GPIM will need to be changed.
In addition, changes to the EPRIM will likely be focused on fine-
tuning the behavior offered by a specific set of model elements.

4. Security Considerations

This informational document presents the framework and workflow of
SUPA,
SUPA as well as an explanation on the relationship of policy, service
and resources. This document does not introduce any new security
issues, and the framework has no security impact on the Internet.

The same considerations are relevant as those for the base NETCONF
protocol (see Section 9 in [RFC6241]).

5. IANA Considerations

This document has no actions for IANA.

8. IANA actions.

6. References

8.1.

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

8.2.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2. Informative References

[I-D.cheng-supa-applicability]

[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.

[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.

[SUPA-APP]
Cheng, Y., Liu, D., Fu, B., Zhang, D., and N. Vadrevu,
"Applicability of SUPA", draft-cheng-supa-applicability-01
(work Work in progress), Progress, draft-cheng-
supa-applicability-01, March 2017.

[I-D.ietf-supa-generic-policy-data-model]

[SUPA-DATA]
Halpern, J. and J. J., Strassner, J., and S. Van der Meer, "Generic
Policy Data Model for Simplified Use of Policy
Abstractions (SUPA)", draft-
ietf-supa-generic-policy-data-model-04 (work Work in progress), Progress, draft-ietf-supa-
generic-policy-data-model-04, June 2017.

[I-D.ietf-supa-generic-policy-info-model]

[SUPA-FRAME]
Zhou, C., Contreras, L., Sun, Q., and P. Yegani, "The
Framework of Simplified Use of Policy Abstractions
(SUPA)", Work in Progress, draft-zhou-supa-framework-02,
May 2015.

[SUPA-INFO]
Strassner, J., Halpern, J., and S. Meer, "Generic Policy
Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-03 (work Work in progress), Progress, draft-ietf-supa-
generic-policy-info-model-03, May 2017.

[I-D.karagiannis-supa-problem-statement]

[SUPA-STATE]
Karagiannis, G., Strassner, J., Qiong, Sun, Q., Contreras, L.,
Yegani, P., and J. Bi, "Problem Statement for Simplified
Use of Policy Abstractions (SUPA)", draft-karagiannis-
supa-problem-statement-07 (work Work in progress), Progress,
draft-karagiannis-supa-problem-statement-07, June 2015.

[I-D.klyus-supa-value-proposition]

[SUPA-VALUE]
Klyus, M., Strassner, J., (Will), S., Liu, W., Karagiannis, G., and J.
Bi, "SUPA Value Proposition", draft-klyus-supa-value-
proposition-00 (work Work in progress), Progress, draft-
klyus-supa-value-proposition-00, March 2016.

[I-D.zhou-supa-framework]
Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The
Framework of Simplified Use of Policy Abstractions
(SUPA)", draft-zhou-supa-framework-02 (work in progress),
May 2015.

[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, DOI 10.17487/RFC3198, November
2001, <https://www.rfc-editor.org/info/rfc3198>.

[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models

Acknowledgements

This document has benefited from reviews, suggestions, comments, and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.

[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.

[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.

6. Contributors

The following people all contributed to creating this document,
listed in alphabetical order:

Ying Chen, China Unicom
Luis M. Contreras, Telefonica I+D
Dan Romascanu, Avaya
Juergen Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom

7. Acknowledgements

This document has benefited from reviews, suggestions, comments and
proposed text provided by
proposed text provided by the following members, listed in
alphabetical order: Andy Bierman, Marc Blanchet, Mohamed Boucadair,
Scott O. Bradner, Scott Cadzow, Zhen Cao, Vikram Choudhary, Benoit
Claise, Spencer Dawkins, Mehmet Ersue, Ian Farrer, Fernando Gont,
Joel Halpern, Jonathan Hansford, Jing Huang, Xing Li, Marco Liebsch,
Diego R. Lopez, Johannes Merkle, Marie-Jose Montpetit, Kostas
Pentikousis, Simon Perreault, Hosnieh Rafiee, Raghav Rao, Jose
Saldana, Jon Saperia, Tom Taylor, Jean Francois Tremblay, Tina Tsou,
Eric Voit, Gunter Wang, Yangyang Wang, Bert Wijnen, and Tianran Zhou.

Part of the initial draft of this document was picked up from
previous documents, and this section lists documents: [SUPA-VALUE], [SUPA-STATE], and [SUPA-FRAME]. We
appreciatively acknowledge the acknowledgements from
them.

From "SUPA Value Proposition" [I-D.klyus-supa-value-proposition] authors, contributors, and
acknowledged parties of those documents.

Contributors

The following people all contributed to creating the creation of this document,
listed in alphabetical order:

Vikram Choudhary, Huawei Technologies

Luis M. Contreras, Telefonica I+D
Dan Romascanu, Avaya
Juergen Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom
Parviz Yegani, Juniper Networks

This document has benefited from reviews, suggestions, comments and
proposed text provided by the following members, listed in
alphabetical order: H. Rafiee, J. Saperia and C. Zhou.

The authors of "SUPA Value Proposition" [I-D.klyus-supa-value-
proposition] were:

Maxim Klyus, Ed. , NetCracker
John Strassner, Ed. , Huawei Technologies
Will(Shucheng) Liu, Huawei Technologies
Georgios Karagiannis, Huawei Technologies
Jun Bi, Tsinghua University

The initial draft of this document merged one document, and this
section lists the acknowledgements from it.

From "Problem Statement for Simplified Use of Policy Abstractions
(SUPA)" [I-D.karagiannis-supa-problem-statement]

The authors of this draft would like to thank the following persons
for the provided valuable feedback and contributions: Diego Lopez,
Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon
Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas
Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Scott
O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. Tina
Tsou, Will Liu and Jean-Francois Tremblay contributed to an early
version of this draft.

The authors of "Problem Statement for Simplified Use of Policy
Abstractions (SUPA)" [I-D.karagiannis-supa-problem-statement] were:

Georgios Karagiannis, Huawei Technologies
Qiong Sun, China Telecom
Luis M. Contreras, Telefonica
Parviz Yegani, Juniper
John Strassner, Huawei Technologies
Jun Bi, Tsinghua University

From "The Framework of Simplified Use of Policy Abstractions (SUPA)"
[I-D.zhou-supa-framework]

The authors of this draft would like to thank the following persons
for the provided valuable feedback: Diego Lopez, Jose Saldana,
Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed
Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios
Karagiannis, John Strassner, Raghav Rao, Jing Huang.

The authors of "The Framework of Simplified Use of Policy
Abstractions (SUPA)" [I-D.zhou-supa-framework] were:
Cathy Zhou, Huawei Technologies
Luis M. Contreras, Telefonica
Qiong Sun, China Telecom
Parviz Yegani, Juniper

Authors' Addresses

Will(Shucheng)

Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
China

Email: liushucheng@huawei.com

Chongfeng Xie
China Telecom
China Telecom Information Technology Innovation Park
Beijing 102209
China

Email: xiechf.bri@chinatelecom.cn

John Strassner
Huawei Technologies
2330 Central Expressway
Santa Clara 95138 Clara, CA USA 95138
United States of America

Email: john.sc.strassner@huawei.com

Georgios Karagiannis
Huawei Technologies
Hansaallee 205
Dusseldorf 40549
Germany

Email: Georgios.Karagiannis@huawei.com
Maxim Klyus
NetCracker
Kozhevnicheskaya str.,7 Bldg. #1
Moscow
Russia

Email: klyus@netcracker.com xmaruto@gmail.com

Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China

Email: junbi@tsinghua.edu.cn

Ying Cheng
China Unicom
No.21 Financial Street, XiCheng District
Beijing 100033
China

Email: chengying10@chinaunicom.cn

Dacheng Zhang
Huawei Technologies
Beijing
China

Email: dacheng.zhang@huawei.com