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