idnits 2.17.1 draft-ietf-supa-policy-based-management-framework-02.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 3, 2017) is 2488 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: 'RFC6020bis' is mentioned on line 108, but not defined == Unused Reference: 'RFC2119' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-data-model' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 630, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 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 4, 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 3, 2017 15 SUPA Policy-based Management Framework 16 draft-ietf-supa-policy-based-management-framework-02 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 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 Traffic flow over increasingly complex enterprise and service 83 provider network becomes 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. 89 Policy rules within an operator's environment can be used to express 90 high-level, possibly network-wide policies to a network management 91 function (within a controller, an orchestrator, or a network 92 element). The network management function can then control the 93 configuration and/or monitoring of network elements and services. 95 Simplified Use of Policy Abstractions (SUPA) defines a generic policy 96 information model (GPIM) [I-D.ietf-supa-generic-policy-info-model] 97 for use in network operations and management applications. The GPIM 98 defines concepts and terminology needed by policy management 99 independent of the form and content of the policy rule. The Event- 100 Condition-Action (ECA) Policy Rule Information Model (EPRIM) [I- 101 D.ietf-supa-generic-policyinfo- model] extends the GPIM by defining 102 how to build policy rules according to the event-condition-action 103 paradigm. 105 Both the GPIM and the EPRIM are targeted at controlling the 106 configuration and monitoring of network elements throughout the 107 service development and deployment lifecycle. The GPIM and the EPRIM 108 can both be translated into corresponding YANG [RFC6020][RFC6020bis] 109 modules that define policy concepts, terminology, and rules in a 110 generic and interoperable manner; additional YANG modules may also be 111 derived from the GPIM and/or EPRIM to manage specific functions. 113 The key benefit of policy management is that it enables different 114 network elements and services to be instructed to behave the same 115 way, even if they are programmed differently. Management 116 applications will benefit from using policy rules that enable 117 scalable and consistent programmatic control over the configuration 118 and monitoring of network elements and services. 120 2. Terminology 122 SUPA: Simplified Use of Policy Abstractions, is the working group 123 name, which defines a data model, to be used to represent high-level, 124 possibly network-wide policies, which can be input to a network 125 management function (within a controller, an orchestrator, or a 126 network element). 128 YANG: an acronym for "Yet Another Next Generation". YANG is a data 129 modeling language used to model configuration and state data 130 manipulated by the Network Configuration Protocol (NETCONF), NETCONF 131 remote procedure calls, and NETCONF notifications.[RFC6020] 133 ECA: Event-Condition-Action, is a short-cut for referring to the 134 structure of active rules in event driven architecture and active 135 database systems. 137 EMS:Element Management System, software to monitor and control 138 network elements (devices) in telecommunications. 140 NMS:Network Management System, a set of hardware and/or software 141 tools that allow an IT professional to supervise the individual 142 components of a network within a larger network management framework. 144 OSS:Operations/Operational Support System, are computer systems used 145 by telecommunications service providers to manage their networks 146 (e.g., telephone networks). 148 BSS:Business Support Systems, are used to support various end-to-end 149 telecommunication services. 151 GPIM: Generic Policy Information Model, which defines concepts and 152 terminology needed by policy management independent of the form and 153 content of the policy rule. 155 EPRIM: ECA Policy Rule Information Model, which extends the GPIM by 156 defining how to build policy rules according to the event-condition- 157 action paradigm. 159 GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data- 160 model], are created from the GPIM. These YANG data model policies 161 are used to control the configuration of network elements that model 162 the service(s) to be managed. The relationship of information model 163 (IM) and DM can be founded in [RFC3444]. 165 Declarative Policy: policies that specify the goals to be achieved 166 but not how to achieve those goals (also called "intent-based" 167 policies). Please note that declarative policies are out of scope 168 for the initial phase of SUPA. 170 3. Framework for Generic Policy-based Management 172 This section briefly describes the design and operation of the SUPA 173 policy-based management framework. 175 3.1. Overview 177 Figure 1 shows a simplified functional architecture of how SUPA is 178 used to define policies for creating network element configuration 179 snippets. (Note from Editor: a "snippet" is a small piece of 180 information (e.g., part of a sentence that was cut out).) SUPA uses 181 the GPIM to define a consensual vocabulary that different actors can 182 use to interact with network elements and services. The EPRIM 183 defines a generic structure for imperative policies. The GPIM, and/ 184 or the combination of the GPIM and the EPRIM, is converted to generic 185 YANG data modules. 187 In one possible approach (shown with asterisks in Figure 1), SUPA 188 Generic Policy and SUPA ECA Policy YANG data modules together with 189 the Resource and Service YANG data models specified in IETF (which 190 define the specific elements that will be controlled by policies) are 191 used by the Service Interface Logic. This Service Interface Logic 192 creates appropriate input mechanisms for the operator to define 193 policies (e.g., a web form or a script) for creating and managing the 194 network configuration. The operator interacts with the interface, 195 the policies input by operators are then translated to configuration 196 snippets. 198 Note that the Resource and Service YANG models may not exist. In 199 this case, the SUPA generic policy YANG data modules serve as an 200 extensible basis to develop new YANG data models for the Service 201 Interface Logic This transfers the work specified by the Resource and 202 Service YANG data models specified in IETF into the Service Interface 203 Logic. 205 +---------------------+ 206 +----------+ \| SUPA | 207 | IETF |---+----+ Information Models | 208 +----------+ | /| GPIM and EPRIM | 209 | +---------+-----------+ 210 Assignments | | Defines Policy Concepts 211 and Manage | \|/ 212 Content | +---------+-----------+ 213 | \| SUPA Generic | 214 +----+ & ECA Policy | 215 /| YANG Data modules | 216 +---------+-----------+ 217 * Possible Approach 218 +-----------------------------*-----------------------------+ 219 | Management System * | 220 | \*/ | 221 | Fills +---------+---------+ +-------------+ | 222 | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+ 223 | |Operator|--------+ Logic +--|Service YANG |----|IETF| 224 | +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+ 225 | scripts |forms, scripts,...)| +-------------+ | 226 | +---------+---------+ | 227 | \|/ | 228 | +-------+--------+ | 229 | | Local Devices | | 230 | | and Management | | 231 | | Systems | | 232 | +----------------+ | 233 +-----------------------------------------------------------+ 235 Figure 1: SUPA Framework 237 Figure 1 is exemplary. The Operator actor shown can interact with 238 SUPA in other ways not shown in Figure 1. In addition, other actors 239 (e.g., an application developer) that can interact with SUPA are not 240 shown for simplicity. 242 The EPRIM defines an ECA policy as an example of imperative policies. 243 An ECA policy rule is activated when its event clause is true; the 244 condition clause is then evaluated and, if true, signals the 245 execution of one or more actions in the action clause. This type of 246 policy explicitly defines the current and desired states of the 247 system being managed. Imperative policy rules require additional 248 management functions, which are explained in section 2.2 below. 250 Figure 2 shows how the SUPA Policy Model is used to create policy 251 data models step by step and how the policy rules are used to 252 communicate among various network management functions located on 253 different layers. 255 The Generic Policy Information Model (GPIM) is used to construct 256 policies. The GPIM defines generic policy concepts, as well as two 257 types of policies: ECA policy rules and declarative policy 258 statements. 260 A set of Generic Policy Data Models (GPDM) are then created from the 261 GPIM. These YANG data model policies are then used to control the 262 configuration of network elements that model the service(s) to be 263 managed. 265 Resource and Service YANG Data Models: models of the service as well 266 as physical and virtual network topology including the resource 267 attributes (e.g., data rate or latency of links) and operational 268 parameters needed to support service deployment over the network 269 topology. 271 | SUPA Policy Model 272 | 273 | +----------------------------------+ 274 | | Generic Policy Information Model | 275 | +----------------------------------+ 276 | D D 277 | D +-------------v-------------+ 278 +----------------------+ | D | ECA Policy Rule | 279 | OSS/BSS/Orchestrator <--+ | D | Information Model | 280 +----------^-----------+ | | D +---------------------------+ 281 C | | D D 282 C | | +----+D+------------------------+D+---+ 283 C +-----+ D SUPA Policy Data Model D | 284 +----------v-----------+ | | ----v-----------------------+ D | 285 | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | 286 +----------^-----------+ | | ----------------------------+ D | 287 C +-----+ D D | 288 C | | | +---------v-----------------v--+ | 289 +----------v-----------+ | | | | ECA Policy Rule Data Model | | 290 | Network Element <--+ | | +------------------------------+ | 291 +----------------------+ | +-------------------------------------+ 292 | 293 | 295 Figure 2: SUPA Policy Model Framework 297 In Figure 2: 299 The double-headed arrow with Cs means communication; 301 The arrow with Ds means derived from. 303 The components within this framework are: 305 SUPA Policy Model: represents one or more policy modules that contain 306 the following entities: 308 Generic Policy Information Model: a model for defining policy rules 309 that are independent of data repository, data definition, query, 310 implementation languages, and protocol. This model is abstract and 311 is used for design; it MUST be turned into a data model for 312 implementation. 314 Generic Policy Data Model: a model of policy rules that are dependent 315 on data repository, data definition, query, implementation languages, 316 and protocol. 318 ECA Policy Rule Information Model (EPRIM): represents a policy rule 319 as a statement that consists of an event clause, a condition clause, 320 and an action clause. This type of Policy Rule explicitly defines 321 the current and desired states of the system being managed. This 322 model is abstract and is used for design; it MUST be turned into a 323 data model for implementation. 325 ECA Policy Rule Data Model: a model of policy rules, derived from 326 EPRIM, while each policy rule consists of an event clause, a 327 condition clause, and an action clause. 329 EMS/NMS/Controller: represents one or more entities that are able to 330 control the operation and management of a network infrastructure 331 (e.g., a network topology that consists of Network Elements). 333 Network Element (NE), which can interact with local or remote 334 EMS/NMS/Controller in order to exchange information, such as 335 configuration information, policy enforcement capabilities, and 336 network status. 338 Relationship between Policy, Service and Resource models can be 339 illustrated by the figure below. 341 +---------------+ +----------------+ 342 | Policy | (1) | Service | 343 | |*******************| | 344 | ( SUPA ) |*******************| ( L3SM, ... ) | 345 +---------------+ +----------------+ 346 ** /*\ 347 ** * 348 ** * 349 (2) ** * (3) 350 ** * 351 ** * 352 ** * 353 +-------------------+ 354 | Resource | 355 | | 356 | (Inventory, ... ) | 357 +-------------------+ 359 Figure 3: Relationship between Policy, Service and Resource models 361 In Figure 3: 363 (1) policy manages and can adjust service behavior as necessary 364 (1:1..n). In addition, data from resources and services are used 365 to select and/or modify policies during runtime. 367 (2) policy manages and can adjust resource behavior as necessary 368 (1:1..n) 369 (3) resource hosts service; changing resources may change service 370 behavior as necessary 372 Policies are used to control the management of resources and 373 services, while data from resources and services are used to select 374 and/or modify policies during runtime. More importantly, policies 375 can be used to manage how resources are allocated and assigned to 376 services. This enables a single policy to manage one or multiple 377 services and resources as well as their dependencies. (1:1..n) in (1) 378 and (2) below figure 3 shows one policy rule is able to manages and 379 can adjust one or multiple services/resources. Line (1) and (2) 380 connecting policy to resource and policy to service are the same, and 381 line (3) connecting resource to service is different as it's 382 navigable only from resource to service. 384 3.2. Operation 386 SUPA can be used to define various types of policies, including 387 policies that affect services and/or the configuration of individual 388 or groups of network elements. SUPA can be used by a centralized 389 and/or distributed set of entities for creating, managing, 390 interacting with, and retiring policy rules. 392 The SUPA scope is limited to policy information and data models. 393 SUPA does not define network resource data models or network service 394 data models; both are out of scope. Instead, SUPA makes use of 395 network resource data models defined by other WGs or SDOs. 397 Declarative policies are out of scope for the initial phase of SUPA. 399 3.3. The GPIM and the EPRIM 401 The GPIM provides a common vocabulary for representing concepts that 402 are common to different types of policy, but which are independent of 403 language, protocol, repository, and level of abstraction. Hence, the 404 GPIM defines concepts and vocabulary needed by policy management 405 systems independent of the form and content of the policy. The EPRIM 406 is a more specific model that refines the GPIM to specify policy 407 rules in an event-condition-action form. 409 This enables different policies at different levels of abstraction to 410 form a continuum, where more abstract policies can be translated into 411 more concrete policies, and vice-versa. For example, the information 412 model can be extended by generalizing concepts from an existing data 413 model into the GPIM; the GPIM extensions can then be used by other 414 data models. 416 3.4. Creation of Generic YANG Modules 418 An information model is abstract. As such, it cannot be directly 419 instantiated (i.e., objects cannot be created directly from it). 420 Therefore, both the GPIM and the combination of the GPIM and the 421 EPRIM, are translated to generic YANG modules. 423 SUPA will provide guidelines for translating the GPIM (or the 424 combination of the GPIM and the EPRIM) into concrete YANG data models 425 that define how to manage and communicate policies between systems. 426 Multiple imperative policy YANG data models may be instantiated from 427 the GPIM (or the combination of the GPIM and the EPRIM). In 428 particular, SUPA will specify a set of YANG data models that will 429 consist of a base policy model for representing policy management 430 concepts independent of the type or structure of a policy, and as 431 well, an extension for defining policy rules according to the ECA 432 paradigm.(Note from Editor: This means that policies can be defined 433 using the GPIM directly, or using the combination of the GPIM and the 434 EPRIM. If you use only the GPIM, you get a technology- and vendor- 435 independent information model that you are free to map to the data 436 model of your choice; note that the structure of a policy is NOT 437 defined. If you use the GPIM and the EPRIM, you get a technology- 438 and vendor-independent information model that defines policies as an 439 event-condition-action (i.e., imperative) rule.) 441 The process of developing the GPIM, EPRIM and the derived/translated 442 YANG data models is realized following the sequence shown below. 443 After completing this process and if the implementation of the YANG 444 data models requires it, the GPIM and EPRIM and the derived/ 445 translated YANG data models are updated and synchronized. 447 (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') 449 Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)= 450 Implementation; (3')= update of YANG data models; (2')=update of 451 EPRIM; (1') = update of GPIM 453 The YANG module derived from the GPIM contains concepts and 454 terminology for the common operation and administration of policy- 455 based systems, as well as an extensible structure for policy rules of 456 different paradigms. The YANG module derived from the EPRIM extends 457 the generic nature of the GPIM by representing policies using an 458 event-condition-action structure. 460 The above sequence allows for the addition of new, as well as the 461 editing of existing model elements in the GPIM and EPRIM. In 462 practice, the implementation sequence may be much simpler. 463 Specifically, it is unlikely that the GPIM will need to be changed. 465 In addition, changes to the EPRIM will likely be focused on fine- 466 tuning the behavior offered by a specific set of model elements. 468 4. Security Considerations 470 TBD 472 5. IANA Considerations 474 This document has no actions for IANA. 476 6. Contributors 478 The following people all contributed to creating this document, 479 listed in alphabetical order: 481 Ying Chen, China Unicom 482 Luis M. Contreras, Telefonica I+D 483 Dan Romascanu, Avaya 484 J. Schoenwaelder, Jacobs University, Germany 485 Qiong Sun, China Telecom 487 7. Acknowledgements 489 This document has benefited from reviews, suggestions, comments and 490 proposed text provided by the following members, listed in 491 alphabetical order: Andy Bierman, Marc Blanchet, Benoit Claise, Joel 492 Halpern, Jonathan Hansford, Diego R. Lopez, Johannes Merkle, Gunter 493 Wang, Bert Wijnen, Tianran Zhou. 495 Part of the initial draft of this document was picked up from 496 previous documents, and this section lists the acknowledgements from 497 them. 499 From "SUPA Value Proposition" [I-D.klyus-supa-value-proposition] 501 The following people all contributed to creating this document, 502 listed in alphabetical order: 504 Vikram Choudhary, Huawei Technologies 505 Luis M. Contreras, Telefonica I+D 506 Dan Romascanu, Avaya 507 J. Schoenwaelder, Jacobs University, Germany 508 Qiong Sun, China Telecom 509 Parviz Yegani, Juniper Networks 511 This document has benefited from reviews, suggestions, comments and 512 proposed text provided by the following members, listed in 513 alphabetical order: H. Rafiee, J. Saperia and C. Zhou. 515 The authors of "SUPA Value Proposition" [I-D.klyus-supa-value- 516 proposition] were: 518 Maxim Klyus, Ed. , NetCracker 519 John Strassner, Ed. , Huawei Technologies 520 Will(Shucheng) Liu, Huawei Technologies 521 Georgios Karagiannis, Huawei Technologies 522 Jun Bi, Tsinghua University 524 The initial draft of this document merged one document, and this 525 section lists the acknowledgements from it. 527 From "Problem Statement for Simplified Use of Policy Abstractions 528 (SUPA)" [I-D.karagiannis-supa-problem-statement] 530 The authors of this draft would like to thank the following persons 531 for the provided valuable feedback and contributions: Diego Lopez, 532 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 533 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon 534 Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas 535 Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Scott 536 O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. Tina 537 Tsou, Will Liu and Jean-Francois Tremblay contributed to an early 538 version of this draft. 540 The authors of "Problem Statement for Simplified Use of Policy 541 Abstractions (SUPA)" [I-D.karagiannis-supa-problem-statement] were: 543 Georgios Karagiannis, Huawei Technologies 544 Qiong Sun, China Telecom 545 Luis M. Contreras, Telefonica 546 Parviz Yegani, Juniper 547 John Strassner, Huawei Technologies 548 Jun Bi, Tsinghua University 550 From "The Framework of Simplified Use of Policy Abstractions (SUPA)" 551 [I-D.zhou-supa-framework] 553 The authors of this draft would like to thank the following persons 554 for the provided valuable feedback: Diego Lopez, Jose Saldana, 555 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 556 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed 557 Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios 558 Karagiannis, John Strassner, Raghav Rao, Jing Huang. 560 The authors of "The Framework of Simplified Use of Policy 561 Abstractions (SUPA)" [I-D.zhou-supa-framework] were: 563 Cathy Zhou, Huawei Technologies 564 Luis M. Contreras, Telefonica 565 Qiong Sun, China Telecom 566 Parviz Yegani, Juniper 568 8. References 570 8.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 8.2. Informative References 579 [I-D.ietf-supa-generic-policy-data-model] 580 Halpern, J. and J. Strassner, "Generic Policy Data Model 581 for Simplified Use of Policy Abstractions (SUPA)", draft- 582 ietf-supa-generic-policy-data-model-04 (work in progress), 583 June 2017. 585 [I-D.ietf-supa-generic-policy-info-model] 586 Strassner, J., Halpern, J., and S. Meer, "Generic Policy 587 Information Model for Simplified Use of Policy 588 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 589 model-03 (work in progress), May 2017. 591 [I-D.karagiannis-supa-problem-statement] 592 Karagiannis, G., Strassner, J., Qiong, Q., Contreras, L., 593 Yegani, P., and J. Bi, "Problem Statement for Simplified 594 Use of Policy Abstractions (SUPA)", draft-karagiannis- 595 supa-problem-statement-07 (work in progress), June 2015. 597 [I-D.klyus-supa-value-proposition] 598 Klyus, M., Strassner, J., (Will), S., Karagiannis, G., and 599 J. Bi, "SUPA Value Proposition", draft-klyus-supa-value- 600 proposition-00 (work in progress), March 2016. 602 [I-D.zhou-supa-framework] 603 Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The 604 Framework of Simplified Use of Policy Abstractions 605 (SUPA)", draft-zhou-supa-framework-02 (work in progress), 606 May 2015. 608 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 609 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 610 J., and S. Waldbusser, "Terminology for Policy-Based 611 Management", RFC 3198, DOI 10.17487/RFC3198, November 612 2001, . 614 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 615 Information Models and Data Models", RFC 3444, 616 DOI 10.17487/RFC3444, January 2003, 617 . 619 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 620 the Network Configuration Protocol (NETCONF)", RFC 6020, 621 DOI 10.17487/RFC6020, October 2010, 622 . 624 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 625 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 626 "Application-Layer Traffic Optimization (ALTO) Protocol", 627 RFC 7285, DOI 10.17487/RFC7285, September 2014, 628 . 630 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 631 RFC 7950, DOI 10.17487/RFC7950, August 2016, 632 . 634 Authors' Addresses 636 Will(Shucheng) Liu 637 Huawei Technologies 638 Bantian, Longgang District 639 Shenzhen 518129 640 P.R. China 642 Email: liushucheng@huawei.com 644 Chongfeng Xie 645 China Telecom Beijing Research Institute 646 China Telecom Information Technology Innovation Park 647 Beijing 102209 648 P.R. China 650 Email: xiechf.bri@chinatelecom.cn 651 John Strassner 652 Huawei Technologies 653 2330 Central Expressway 654 Santa Clara 95138 655 CA USA 657 Email: john.sc.strassner@huawei.com 659 Georgios Karagiannis 660 Huawei Technologies 661 Hansaallee 205 662 Dusseldorf 40549 663 Germany 665 Email: Georgios.Karagiannis@huawei.com 667 Maxim Klyus 668 NetCracker 669 Kozhevnicheskaya str.,7 Bldg. #1 670 Moscow 671 Russia 673 Email: klyus@netcracker.com 675 Jun Bi 676 Tsinghua University 677 Network Research Center, Tsinghua University 678 Beijing 100084 679 P.R. China 681 Email: junbi@tsinghua.edu.cn