Policies are a set of rules that define how services are designed, delivered, and operated within an operator's networking environment. As such, policies play a critical role in the automated service delivery and operational procedures. Operators want and need to be able to define the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. Policies usually span a wide range of services that are supported by various technologies: thus, a common way for expressing and describing policies that is uniform and consistent regardless of the nature of the networking environment is likely to facilitate the overall service delivery procedure and operation. Such an approach will minimize the risk of configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements. The SUPA (Simplified Use of Policy Abstractions) working group defines a data model, to be used to represent high-level, possibly network-wide policies, which can be input to a network management function (within a controller, an orchestrator, or a network element). Processing that input most probably results in network configuration changes. SUPA however does not deal with the definition of the specific network configuration changes but with how the configuration changes are applied (e.g. who is allowed to set policies, when and how the policies are activated, changed or de-activated). Practically, SUPA defines base YANG data models to encode policy, which will point to device-, technology-, and service-specific YANG models developed in other working groups. SUPA focuses on a single management domain, and is designed to work with device, protocol, network, and service data models. The working group will have succeeded when the SUPA policy constructs are re-used in future IETF specifications (and ideally specifications from other SDOs), in a matter that saves development time and avoid inconsistencies between data models developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA to produce its deliverables. In the mean time, other working groups should not delay their deliverables waiting for SUPA to complete its work. The SUPA working group develops models for expressing policy at different levels of abstraction. Specifically, two models are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC. Out of scope of this working group are: - The specification of a new policy protocol or a new data modelling language. - Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes). - Specific handling of policies (although the application document will provide some examples). Therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets is also out of scope. Declarative policies that specify the goals to achieve but not how to achieve those goals (also called "intent-based" policies) are out of scope for the initial phase of SUPA but may be considered in future phases of SUPA. List of work items: 1) An explanation of the scope of the policy-based management framework and how it relates to existing work of the IETF. 2) If the working group considers it necessary, a generic information model composed of policy concepts and vocabulary. 3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. 4) An applicability document providing a few examples that demonstrate how the YANG policy data models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups. The working group will decide how the work items are best mapped into deliverables. The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues. Milestones: Apr 2016 Submit the policy-based management framework (Informational) Apr 2016 Submit the generic information model (Informational) Jun 2016 Submit the set of YANG data models (Standards Track) Aug 2016 Submit the applicability document (Informational) Aug 2016 Re-charter or close