idnits 2.17.1 draft-liu-policy-based-management-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 27, 2017) is 2401 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-supa-generic-policyinfo-model' is mentioned on line 111, but not defined == Missing Reference: 'RFC6020bis' is mentioned on line 118, but not defined == Unused Reference: 'RFC2119' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-data-model' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-info-model' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 656, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Informational C. Xie 5 Expires: March 31, 2018 China Telecom 6 J. Strassner 7 G. Karagiannis 8 Huawei Technologies 9 M. Klyus 10 NetCracker 11 J. Bi 12 Tsinghua University 13 Y. Cheng 14 China Unicom 15 D. Zhang 16 Huawei Technologies 17 September 27, 2017 19 SUPA Policy-based Management Framework 20 draft-liu-policy-based-management-framework-00 22 Abstract 24 Simplified Use of Policy Abstractions (SUPA) defines base YANG data 25 models to encode policy, which point to device-, technology-, and 26 service-specific YANG models developed elsewhere. Policy rules 27 within an operator's environment can be used to express high-level, 28 possibly network-wide policies to a network management function 29 (within a controller, an orchestrator, or a network element). The 30 network management function can then control the configuration and/or 31 monitoring of network elements and services. This document describes 32 the SUPA basic framework, its elements and interfaces. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 31, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Framework for Generic Policy-based Management . . . . . . . . 4 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 10 73 3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 10 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 8.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 Traffic flows over increasingly complex enterprise and service 86 provider networks become more and more important. Meanwhile, the 87 rapid growth of the variety makes the task of network operations and 88 management applications deploying new services much more difficult. 89 Moreover, network operators want to deploy new services quickly and 90 efficiently. Two possible mechanisms for dealing with this growing 91 difficulty are the use of software abstractions to simplify the 92 design and configuration of monitoring and control operations, and 93 the use of programmatic control over the configuration and operation 94 of such networks. Policy-based management can be used to combine 95 these two mechanisms into an extensible framework. 97 Policy rules within an operator's environment are a set of rules that 98 define how services are designed, delivered, and operated. The SUPA 99 (Simplified Use of Policy Abstractions) data model represents high- 100 level, possibly network-wide policy, which can be input to a network 101 management function (within a controller, an orchestrator, or a 102 network element).The network management function can then control the 103 configuration and/or monitoring of network elements and services 104 according to such policies. 106 SUPA defines a generic policy information model (GPIM) [I-D.ietf- 107 supa-generic-policy-info-model] for use in network operations and 108 management applications. The GPIM defines concepts and terminology 109 needed by policy management independent of the form and content of 110 the policy rule. The Event-Condition-Action (ECA) Policy Rule 111 Information Model (EPRIM) [I-D.ietf-supa-generic-policyinfo-model] 112 extends the GPIM by defining how to build policy rules according to 113 the event-condition-action paradigm. 115 Both the GPIM and the EPRIM are targeted at controlling the 116 configuration and monitoring of network elements throughout the 117 service development and deployment lifecycle. The GPIM and the EPRIM 118 can both be translated into corresponding YANG [RFC6020][RFC6020bis] 119 modules that define policy concepts, terminology, and rules in a 120 generic and interoperable manner; additional YANG modules may also be 121 derived from the GPIM and/or EPRIM to manage specific functions. 123 The key benefit of policy management is that it enables different 124 network elements and services to be instructed to behave the same 125 way, even if they are programmed differently. Management 126 applications will benefit from using policy rules that enable 127 scalable and consistent programmatic control over the configuration 128 and monitoring of network elements and services. 130 Some typical and useful instances, for authors to understand the 131 applicability of SUPA, such as SNMP blocking upon load of link 132 reaching a threshold, virtual maching migration upon the changinng of 133 user location, are written in [I-D.cheng-supa-applicability]. 135 2. Terminology 137 SUPA: Simplified Use of Policy Abstractions, is the working group 138 name, which defines a data model, to be used to represent high-level, 139 possibly network-wide policies, which can be input to a network 140 management function (within a controller, an orchestrator, or a 141 network element). 143 YANG: an acronym for "Yet Another Next Generation". YANG is a data 144 modeling language used to model configuration and state data 145 manipulated by the Network Configuration Protocol (NETCONF), NETCONF 146 remote procedure calls, and NETCONF notifications.[RFC6020] 148 ECA: Event-Condition-Action, is a short-cut for referring to the 149 structure of active rules in event driven architecture and active 150 database systems. 152 EMS: Element Management System, software to monitor and control 153 network elements (devices) in telecommunications. 155 NMS: Network Management System, a set of hardware and/or software 156 tools that allow an IT professional to supervise the individual 157 components of a network within a larger network management framework. 159 OSS: Operations/Operational Support System, are computer systems used 160 by telecommunications service providers to manage their networks 161 (e.g., telephone networks). 163 BSS: Business Support Systems, are used to support various end-to-end 164 telecommunication services. 166 GPIM: Generic Policy Information Model, which defines concepts and 167 terminology needed by policy management independent of the form and 168 content of the policy rule. 170 EPRIM: ECA Policy Rule Information Model, which extends the GPIM by 171 defining how to build policy rules according to the event-condition- 172 action paradigm. 174 GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data- 175 model], are created from the GPIM. These YANG data model policies 176 are used to control the configuration of network elements that model 177 the service(s) to be managed. The relationship of information model 178 (IM) and DM can be founded in [RFC3444]. 180 Declarative Policy: policies that specify the goals to be achieved 181 but not how to achieve those goals (also called "intent-based" 182 policies). Please note that declarative policies are out of scope 183 for the initial phase of SUPA. 185 3. Framework for Generic Policy-based Management 187 This section briefly describes the design and operation of the SUPA 188 policy-based management framework. 190 3.1. Overview 192 Figure 1 shows a simplified functional architecture of how SUPA is 193 used to define policies for creating network element configuration 194 snippets. (Note from Editor: a "snippet" is a small piece of 195 information (e.g., part of a sentence that was cut out).) SUPA uses 196 the GPIM to define a consensual vocabulary that different actors can 197 use to interact with network elements and services. The EPRIM 198 defines a generic structure for imperative policies. The GPIM, and/ 199 or the combination of the GPIM and the EPRIM, is converted to generic 200 YANG data modules. 202 In one possible approach (shown with asterisks in Figure 1), SUPA 203 Generic Policy and SUPA ECA Policy YANG data modules together with 204 the Resource and Service YANG data models specified in IETF (which 205 define the specific elements that will be controlled by policies) are 206 used by the Service Interface Logic. This Service Interface Logic 207 creates appropriate input mechanisms for the operator to define 208 policies (e.g., a web form or a script) for creating and managing the 209 network configuration. The operator interacts with the interface, 210 the policies input by operators are then translated to configuration 211 snippets. 213 Note that the Resource and Service YANG models may not exist. In 214 this case, the SUPA generic policy YANG data modules serve as an 215 extensible basis to develop new YANG data models for the Service 216 Interface Logic This transfers the work specified by the Resource and 217 Service YANG data models specified in IETF into the Service Interface 218 Logic. 220 +---------------------+ 221 +----------+ \| SUPA | 222 | IETF |---+----+ Information Models | 223 +----------+ | /| GPIM and EPRIM | 224 | +---------+-----------+ 225 Assignments | | Defines Policy Concepts 226 and Manage | \|/ 227 Content | +---------+-----------+ 228 | \| SUPA Generic | 229 +----+ & ECA Policy | 230 /| YANG Data modules | 231 +---------+-----------+ 232 * Possible Approach 233 +-----------------------------*-----------------------------+ 234 | Management System * | 235 | \*/ | 236 | Fills +---------+---------+ +-------------+ | 237 | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+ 238 | |Operator|--------+ Logic +--|Service YANG |----|IETF| 239 | +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+ 240 | scripts |forms, scripts,...)| +-------------+ | 241 | +---------+---------+ | 242 | \|/ | 243 | +-------+--------+ | 244 | | Local Devices | | 245 | | and Management | | 246 | | Systems | | 247 | +----------------+ | 248 +-----------------------------------------------------------+ 250 Figure 1: SUPA Framework 252 Figure 1 is exemplary. The Operator actor can interact with SUPA in 253 other ways not shown in Figure 1. In addition, other actors (e.g., 254 an application developer) that can interact with SUPA are not shown 255 for simplicity. 257 The EPRIM defines an ECA policy as an example of imperative policies. 258 An ECA policy rule is activated when its event clause is true; the 259 condition clause is then evaluated and, if true, signals the 260 execution of one or more actions in the action clause. This type of 261 policy explicitly defines the current and desired states of the 262 system being managed. Imperative policy rules require additional 263 management functions, which are explained in section 3.2 below. 265 Figure 2 shows how the SUPA Policy Model is used to create policy 266 data models step by step and how the policy rules are used to 267 communicate among various network management functions located on 268 different layers. 270 The Generic Policy Information Model (GPIM) is used to construct 271 policies. The GPIM defines generic policy concepts, as well as two 272 types of policies: ECA policy rules and declarative policy 273 statements. 275 A set of Generic Policy Data Models (GPDM) are then created from the 276 GPIM. These YANG data model policies are then used to control the 277 configuration of network elements that model the service(s) to be 278 managed. 280 Resource and Service YANG Data Models: models of the service as well 281 as physical and virtual network topology including the resource 282 attributes (e.g., data rate or latency of links) and operational 283 parameters needed to support service deployment over the network 284 topology. 286 | SUPA Policy Model 287 | 288 | +----------------------------------+ 289 | | Generic Policy Information Model | 290 | +----------------------------------+ 291 | D D 292 | D +-------------v-------------+ 293 +----------------------+ | D | ECA Policy Rule | 294 | OSS/BSS/Orchestrator <--+ | D | Information Model | 295 +----------^-----------+ | | D +---------------------------+ 296 C | | D D 297 C | | +----+D+------------------------+D+---+ 298 C +-----+ D SUPA Policy Data Model D | 299 +----------v-----------+ | | ----v-----------------------+ D | 300 | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | 301 +----------^-----------+ | | ----------------------------+ D | 302 C +-----+ D D | 303 C | | | +---------v-----------------v--+ | 304 +----------v-----------+ | | | | ECA Policy Rule Data Model | | 305 | Network Element <--+ | | +------------------------------+ | 306 +----------------------+ | +-------------------------------------+ 307 | 308 | 310 Figure 2: SUPA Policy Model Framework 312 In Figure 2: 314 The double-headed arrow with Cs means communication; 315 The arrow with Ds means derived from. 317 The components within this framework are: 319 SUPA Policy Model: represents one or more policy modules that contain 320 the following entities: 322 Generic Policy Information Model: a model for defining policy rules 323 that are independent of data repository, data definition, query, 324 implementation languages, and protocol. This model is abstract and 325 is used for design; it MUST be turned into a data model for 326 implementation. 328 Generic Policy Data Model: a model of policy rules that are dependent 329 on data repository, data definition, query, implementation languages, 330 and protocol. 332 ECA Policy Rule Information Model (EPRIM): represents a policy rule 333 as a statement that consists of an event clause, a condition clause, 334 and an action clause. This type of Policy Rule explicitly defines 335 the current and desired states of the system being managed. This 336 model is abstract and is used for design; it MUST be turned into a 337 data model for implementation. 339 ECA Policy Rule Data Model: a model of policy rules, derived from 340 EPRIM, while each policy rule consists of an event clause, a 341 condition clause, and an action clause. 343 EMS/NMS/Controller: represents one or more entities that are able to 344 control the operation and management of a network infrastructure 345 (e.g., a network topology that consists of Network Elements). 347 Network Element (NE), which can interact with local or remote 348 EMS/NMS/Controller in order to exchange information, such as 349 configuration information, policy enforcement capabilities, and 350 network status. 352 Relationship between Policy, Service and Resource models can be 353 illustrated by the figure below. 355 +---------------+ +----------------+ 356 | Policy | (1) | Service | 357 | |*******************| | 358 | ( SUPA ) |*******************| ( L3SM, ... ) | 359 +---------------+ +----------------+ 360 ** /*\ 361 ** * 362 ** * 363 (2) ** * (3) 364 ** * 365 ** * 366 ** * 367 +-------------------+ 368 | Resource | 369 | | 370 | (Inventory, ... ) | 371 +-------------------+ 373 Figure 3: Relationship between Policy, Service and Resource models 375 In Figure 3: 377 (1) policy manages and can adjust service behavior as necessary 378 (1:1..n). In addition, data from resources and services are used 379 to select and/or modify policies during runtime. 380 (2) policy manages and can adjust resource behavior as necessary 381 (1:1..n) 382 (3) resource hosts service; changing resources may change service 383 behavior as necessary 385 Policies are used to control the management of resources and 386 services, while data from resources and services are used to select 387 and/or modify policies during runtime. More importantly, policies 388 can be used to manage how resources are allocated and assigned to 389 services. This enables a single policy to manage one or multiple 390 services and resources as well as their dependencies. (1:1..n) in (1) 391 and (2) below figure 3 show one policy rule is able to manages and 392 can adjust one or multiple services/resources. Line (1) and (2) 393 connecting policy to resource and policy to service are the same, and 394 line (3) connecting resource to service is different as it's 395 navigable only from resource to service. 397 3.2. Operation 399 SUPA can be used to define various types of policies, including 400 policies that affect services and/or the configuration of individual 401 or groups of network elements. SUPA can be used by a centralized 402 and/or distributed set of entities for creating, managing, 403 interacting with, and retiring policy rules. 405 The SUPA scope is limited to policy information and data models. 406 SUPA does not define network resource data models or network service 407 data models; both are out of scope. Instead, SUPA makes use of 408 network resource data models defined by other WGs or SDOs. 410 Declarative policies are out of scope for the initial phase of SUPA. 412 3.3. The GPIM and the EPRIM 414 The GPIM provides a common vocabulary for representing concepts that 415 are common to different types of policy, but which are independent of 416 language, protocol, repository, and level of abstraction. Hence, the 417 GPIM defines concepts and vocabulary needed by policy management 418 systems independent of the form and content of the policy. The EPRIM 419 is a more specific model that refines the GPIM to specify policy 420 rules in an event-condition-action form. 422 This enables different policies at different levels of abstraction to 423 form a continuum, where more abstract policies can be translated into 424 more concrete policies, and vice-versa. For example, the information 425 model can be extended by generalizing concepts from an existing data 426 model into the GPIM; the GPIM extensions can then be used by other 427 data models. 429 3.4. Creation of Generic YANG Modules 431 An information model is abstract. As such, it cannot be directly 432 instantiated (i.e., objects cannot be created directly from it). 433 Therefore, both the GPIM and the combination of the GPIM and the 434 EPRIM, are translated to generic YANG modules. 436 SUPA will provide guidelines for translating the GPIM (or the 437 combination of the GPIM and the EPRIM) into concrete YANG data models 438 that define how to manage and communicate policies between systems. 439 Multiple imperative policy YANG data models may be instantiated from 440 the GPIM (or the combination of the GPIM and the EPRIM). In 441 particular, SUPA will specify a set of YANG data models that will 442 consist of a base policy model for representing policy management 443 concepts independent of the type or structure of a policy, and as 444 well, an extension for defining policy rules according to the ECA 445 paradigm.(Note from Editor: This means that policies can be defined 446 using the GPIM directly, or using the combination of the GPIM and the 447 EPRIM. If you use only the GPIM, you get a technology- and vendor- 448 independent information model that you are free to map to the data 449 model of your choice; note that the structure of a policy is NOT 450 defined. If you use the GPIM and the EPRIM, you get a technology- 451 and vendor-independent information model that defines policies as an 452 event-condition-action (i.e., imperative) rule.) 454 The process of developing the GPIM, EPRIM and the derived/translated 455 YANG data models is realized following the sequence shown below. 456 After completing this process and if the implementation of the YANG 457 data models requires it, the GPIM and EPRIM and the derived/ 458 translated YANG data models are updated and synchronized. 460 (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') 462 Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)= 463 Implementation; (3')= update of YANG data models; (2')=update of 464 EPRIM; (1') = update of GPIM 466 The YANG module derived from the GPIM contains concepts and 467 terminology for the common operation and administration of policy- 468 based systems, as well as an extensible structure for policy rules of 469 different paradigms. The YANG module derived from the EPRIM extends 470 the generic nature of the GPIM by representing policies using an 471 event-condition-action structure. 473 The above sequence allows for the addition of new, as well as the 474 editing of existing model elements in the GPIM and EPRIM. In 475 practice, the implementation sequence may be much simpler. 476 Specifically, it is unlikely that the GPIM will need to be changed. 477 In addition, changes to the EPRIM will likely be focused on fine- 478 tuning the behavior offered by a specific set of model elements. 480 4. Security Considerations 482 This informational document presents the framework and workflow of 483 SUPA, as well as an explanation on the relationship of policy, 484 service and resources. This document does not introduce any new 485 security issues, and the framework has no security impact on the 486 Internet. The same considerations are relevant as those for the base 487 NETCONF protocol (see Section 9 in [RFC6241]). 489 5. IANA Considerations 491 This document has no actions for IANA. 493 6. Contributors 495 The following people all contributed to creating this document, 496 listed in alphabetical order: 498 Ying Chen, China Unicom 499 Luis M. Contreras, Telefonica I+D 500 Dan Romascanu, Avaya 501 Juergen Schoenwaelder, Jacobs University, Germany 502 Qiong Sun, China Telecom 504 7. Acknowledgements 506 This document has benefited from reviews, suggestions, comments and 507 proposed text provided by the following members, listed in 508 alphabetical order: Andy Bierman, Marc Blanchet, Benoit Claise, Joel 509 Halpern, Jonathan Hansford, Diego R. Lopez, Johannes Merkle, Gunter 510 Wang, Yangyang Wang, Bert Wijnen, Tianran Zhou. 512 Part of the initial draft of this document was picked up from 513 previous documents, and this section lists the acknowledgements from 514 them. 516 From "SUPA Value Proposition" [I-D.klyus-supa-value-proposition] 518 The following people all contributed to creating this document, 519 listed in alphabetical order: 521 Vikram Choudhary, Huawei Technologies 522 Luis M. Contreras, Telefonica I+D 523 Dan Romascanu, Avaya 524 Juergen Schoenwaelder, Jacobs University, Germany 525 Qiong Sun, China Telecom 526 Parviz Yegani, Juniper Networks 528 This document has benefited from reviews, suggestions, comments and 529 proposed text provided by the following members, listed in 530 alphabetical order: H. Rafiee, J. Saperia and C. Zhou. 532 The authors of "SUPA Value Proposition" [I-D.klyus-supa-value- 533 proposition] were: 535 Maxim Klyus, Ed. , NetCracker 536 John Strassner, Ed. , Huawei Technologies 537 Will(Shucheng) Liu, Huawei Technologies 538 Georgios Karagiannis, Huawei Technologies 539 Jun Bi, Tsinghua University 541 The initial draft of this document merged one document, and this 542 section lists the acknowledgements from it. 544 From "Problem Statement for Simplified Use of Policy Abstractions 545 (SUPA)" [I-D.karagiannis-supa-problem-statement] 546 The authors of this draft would like to thank the following persons 547 for the provided valuable feedback and contributions: Diego Lopez, 548 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 549 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon 550 Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas 551 Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Scott 552 O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. Tina 553 Tsou, Will Liu and Jean-Francois Tremblay contributed to an early 554 version of this draft. 556 The authors of "Problem Statement for Simplified Use of Policy 557 Abstractions (SUPA)" [I-D.karagiannis-supa-problem-statement] were: 559 Georgios Karagiannis, Huawei Technologies 560 Qiong Sun, China Telecom 561 Luis M. Contreras, Telefonica 562 Parviz Yegani, Juniper 563 John Strassner, Huawei Technologies 564 Jun Bi, Tsinghua University 566 From "The Framework of Simplified Use of Policy Abstractions (SUPA)" 567 [I-D.zhou-supa-framework] 569 The authors of this draft would like to thank the following persons 570 for the provided valuable feedback: Diego Lopez, Jose Saldana, 571 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 572 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed 573 Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios 574 Karagiannis, John Strassner, Raghav Rao, Jing Huang. 576 The authors of "The Framework of Simplified Use of Policy 577 Abstractions (SUPA)" [I-D.zhou-supa-framework] were: 579 Cathy Zhou, Huawei Technologies 580 Luis M. Contreras, Telefonica 581 Qiong Sun, China Telecom 582 Parviz Yegani, Juniper 584 8. References 586 8.1. Normative References 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 8.2. Informative References 595 [I-D.cheng-supa-applicability] 596 Cheng, Y., Liu, D., Fu, B., Zhang, D., and N. Vadrevu, 597 "Applicability of SUPA", draft-cheng-supa-applicability-01 598 (work in progress), March 2017. 600 [I-D.ietf-supa-generic-policy-data-model] 601 Halpern, J. and J. Strassner, "Generic Policy Data Model 602 for Simplified Use of Policy Abstractions (SUPA)", draft- 603 ietf-supa-generic-policy-data-model-04 (work in progress), 604 June 2017. 606 [I-D.ietf-supa-generic-policy-info-model] 607 Strassner, J., Halpern, J., and S. Meer, "Generic Policy 608 Information Model for Simplified Use of Policy 609 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 610 model-03 (work in progress), May 2017. 612 [I-D.karagiannis-supa-problem-statement] 613 Karagiannis, G., Strassner, J., Qiong, Q., Contreras, L., 614 Yegani, P., and J. Bi, "Problem Statement for Simplified 615 Use of Policy Abstractions (SUPA)", draft-karagiannis- 616 supa-problem-statement-07 (work in progress), June 2015. 618 [I-D.klyus-supa-value-proposition] 619 Klyus, M., Strassner, J., (Will), S., Karagiannis, G., and 620 J. Bi, "SUPA Value Proposition", draft-klyus-supa-value- 621 proposition-00 (work in progress), March 2016. 623 [I-D.zhou-supa-framework] 624 Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The 625 Framework of Simplified Use of Policy Abstractions 626 (SUPA)", draft-zhou-supa-framework-02 (work in progress), 627 May 2015. 629 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 630 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 631 J., and S. Waldbusser, "Terminology for Policy-Based 632 Management", RFC 3198, DOI 10.17487/RFC3198, November 633 2001, . 635 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 636 Information Models and Data Models", RFC 3444, 637 DOI 10.17487/RFC3444, January 2003, 638 . 640 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 641 the Network Configuration Protocol (NETCONF)", RFC 6020, 642 DOI 10.17487/RFC6020, October 2010, 643 . 645 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 646 and A. Bierman, Ed., "Network Configuration Protocol 647 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 648 . 650 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 651 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 652 "Application-Layer Traffic Optimization (ALTO) Protocol", 653 RFC 7285, DOI 10.17487/RFC7285, September 2014, 654 . 656 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 657 RFC 7950, DOI 10.17487/RFC7950, August 2016, 658 . 660 Authors' Addresses 662 Will(Shucheng) Liu 663 Huawei Technologies 664 Bantian, Longgang District 665 Shenzhen 518129 666 China 668 Email: liushucheng@huawei.com 670 Chongfeng Xie 671 China Telecom 672 China Telecom Information Technology Innovation Park 673 Beijing 102209 674 China 676 Email: xiechf.bri@chinatelecom.cn 678 John Strassner 679 Huawei Technologies 680 2330 Central Expressway 681 Santa Clara 95138 682 CA USA 684 Email: john.sc.strassner@huawei.com 685 Georgios Karagiannis 686 Huawei Technologies 687 Hansaallee 205 688 Dusseldorf 40549 689 Germany 691 Email: Georgios.Karagiannis@huawei.com 693 Maxim Klyus 694 NetCracker 695 Kozhevnicheskaya str.,7 Bldg. #1 696 Moscow 697 Russia 699 Email: klyus@netcracker.com 701 Jun Bi 702 Tsinghua University 703 Network Research Center, Tsinghua University 704 Beijing 100084 705 China 707 Email: junbi@tsinghua.edu.cn 709 Ying Cheng 710 China Unicom 711 No.21 Financial Street, XiCheng District 712 Beijing 100033 713 China 715 Email: chengying10@chinaunicom.cn 717 Dacheng Zhang 718 Huawei Technologies 719 Beijing 720 China 722 Email: dacheng.zhang@huawei.com