--- 1/draft-ietf-i2nsf-terminology-02.txt 2017-03-07 12:13:10.718580340 -0800 +++ 2/draft-ietf-i2nsf-terminology-03.txt 2017-03-07 12:13:10.746581000 -0800 @@ -1,24 +1,23 @@ - I2NSF S. Hares Internet-Draft J. Strassner Intended status: Informational Huawei -Expires: April 25, 2017 D. Lopez +Expires: September 07, 2017 D. Lopez Telefonica I+D L. Xia Huawei H. Birkholz Fraunhofer SIT - October 23, 2016 + March 07, 2017 Interface to Network Security Functions (I2NSF) Terminology - draft-ietf-i2nsf-terminology-02.txt + draft-ietf-i2nsf-terminology-03.txt Abstract This document defines a set of terms that are used for the Interface to Network Security Functions (I2NSF) effort. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -27,25 +26,25 @@ Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 25, 2017. + This Internet-Draft will expire on September 07, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided @@ -116,104 +115,81 @@ objects. It manages complexity by exposing common properties between objects and processes while hiding detail that is not relevant. Access Control: Protection of system resources against unauthorized access; a process by which use of system resources is regulated according to a security policy, and is permitted by only authorized entities (users, programs, processes, or other systems) according to that policy [RFC4949]. - Accounting: The act of collecting information on resource usage for - the purpose of trend analysis, auditing, billing, or cost - allocation ([RFC2975] [RFC3539]). - - ACL (Access Control List): This is a mechanism that implements + Access Control List (ACL): This is a mechanism that implements access control for a system resource by enumerating the system entities that are permitted to access the resource and stating, either implicitly or explicitly, the access modes granted to each entity [RFC4949]. A YANG description is defined in [I-D.ietf-netmod-acl-model]. - Action: Defines what is to be done when a set of Conditions are - met (See I2NSF Action). (from - [I-D.ietf-supa-generic-policy-info-model]). + Accounting: The act of collecting information on resource usage for + the purpose of trend analysis, auditing, billing, or cost + allocation ([RFC2975] [RFC3539]). Assertion: Defined by the ITU in [X.1252] as "a statement made by an entity without accompanying evidence of its validity". In the context of I2NSF, an assertion MAY include metadata about all or part of the assertion (e.g., context of the assertion, or about timestamp indicating the point in time the assertion was created). The validity of an assertion cannot be verified. (from [I-D.ietf-sacm-terminology]). + Attestation: The process of validating the integrity of a computing + device. See also Direct Anonymous Attestation. + Authentication: Defined in [RFC4949] as "the process of verifying a claim that a system entity or system resource has a certain attribute value." (from [I-D.ietf-sacm-terminology]). Authorization: Defined in [RFC4949] as "an approval that is granted to a system entity to access a system resource." (from [I-D.ietf-sacm-terminology]). - B2B: Business-to-Business. + Business-to-Business (B2B). A type of transaction in which one + business makes a commercial transaction with another business. + + Business-to-Consumer (B2C). A type of transaction in which a + business makes a commercial transaction with a Customer. Bespoke: Something made to fit a particular person, customer, or company. Bespoke security management: Security management systems that are - make to fit a particular customer. + made to fit a particular customer. Boolean Clause: A logical statement that evaluates to either TRUE or FALSE. Also called Boolean Expression. - Capability: Defines a set of features that are available from a - managed entity (see also I2NSF Capability). Examples of "managed - entities" are NSFs and Controllers, where NSF Capabilities and - Controller Capabilities define functionality of an NSF and about - Controller, respectively. These functions may, but do not have - to, be used. All Capabilities are announced through the - Registration Interface. + Capability: A set of features that are available from an I2NSF + Component. These functions may, but do not have to, be used. All + Capabilities are announced through the I2NSF Registration + Interface. Examples are Capabilities that are available from an + NSF Server. - Client: See Consumer. [Editor's note: placeholder for gradually - replacing Client with Consumer, since Client is too vague and - has other connotations (e.g., client-server)]. + Client: See I2NSF Consumer. - Client-Facing Interface: See Consumer-Facing Interface. - See also: Interface, NSF-Facing Interface. + Client-Facing Interface: See I2NSF Consumer-Facing Interface. Component: An encapsulation of software that communicates using Interfaces. A Component may be implemented by hardware and/or software, and be represented using a set of classes. In general, a Component encapsulates a set of data structures and a set of algorithms that implement the function(s) that it provides. - Consumer: A Consumer is a Role that is assigned to an I2NSF - Component that represents the needs of a user of I2NSF services. - A consumer can send/receive information to/from another I2NSF - Component (e.g., for defining and monitoring security policies - for the Consumer's specific flows through an I2NSF - administrative domain). See also: Producer, Role. - - Consumer-Facing Interface: An Interface dedicated to communication - with Consumers of NSF Data and Services. This is typically - defined per I2NSF administrative domain. See also: Interface, - NSF-Facing Interface. - - Condition: A set of attributes, features, and/or values that are to - be compared with a set of known attributes, features, and/or - values in order to make a decision. A Condition, when used in the - context of a Policy Rule, is used to determine whether or not the - set of Actions in that Policy Rule can be executed or not. - Examples of an I2NSF Condition include matching attributes of a - packet or flow, and comparing the internal state of a NSF to a - desired state. (from [I-D.ietf-supa-generic-policy-info-model]). - Constraint: A Constraint is a limitation or restriction. Constraints may be associated with any type of object (e.g., Events, Conditions, and Actions in Policy Rules). Constraint Programming: A type of programming that uses constraints to define relations between variables in order to find a feasible (and not necessarily optimal) solution. Context: The Context of an Entity is a collection of measured and/ or inferred knowledge that describe the state and the environment @@ -235,48 +211,57 @@ with Interfaces to the Control Plane have knowledge of the Capabilities of other I2NSF Components within a particular I2NSF administrative domain. This definition is based on that in [I-D.ietf-sacm-terminology]. See also: Data Plane, Management Plane. Customer: A business role of an entity that is involved in the definition and/or consumption of services, and the possible negotiation of a contract to use services from a Provider. - DC: Data Center + Data Center (DC): A facility used to house data processing and + communication equipment. + + Data Confidentiality: Defined in [RFC4949] as "the property that + data is not disclosed to system entities unless they have been + authorized to know the data." + + Data Integrity: Defined in [RFC4949] as "the property that data has + not been changed, destroyed, or lost in an unauthorized or + accidental manner." + Data Model: A representation of concepts of interest to an environment in a form that is dependent on data repository, data definition language, query language, implementation language, and protocol (typically one or more of these ). Note the difference between a data **model** and a data **structure**. [I-D.ietf-supa-generic-policy-info-model]. Data Plane: In the context of I2NSF, the Data Plane is an architectural Component that provides operational functions to enable an I2NSF Component to provide and consume packets and flows. See also: Control Plane, Management Plane. + Data Provenance: A historical record of the sources, origins and + evolution of data that is influenced by inputs, entities, + functions and processes. + Data Structure: A low-level building block that is used in programming to implement an algorithm. A data model typically contains multiple types of data structures; however, a data structure does not contain a data model. Note the difference between a data **model** and a data **structure**. - Event: An important occurrence in time of a change in the system - being managed, and/or in the environment of the system being - managed. Examples of an I2NSF Event include time and user actions - (e.g. logon, logoff, and actions that violate an ACL). An Event, - when used in the context of a Policy Rule, is used to determine - whether the Condition clause of an imperative Policy Rule can be - evaluated or not (from [I-D.ietf-supa-generic-policy-info-model]). - - ECA: Event - Condition - Action (a type of Policy Rule). + Direct Anonymous Attestation (DAA): A cryptographic primitive that + enables remote authentication of a trusted computer without + compromising the privacy of that computer's user(s). See also + attestation. Firewall (FW): A function that restricts data communication traffic to and from one of the connected networks (the one said to be 'inside' the firewall), and thus protects that network's system resources against threats from the other network (the one that is said to be 'outside' the firewall) [RFC4949]. [I-D.ietf-opsawg-firewalls] Flow: A set of information (e.g., packets) that are related in a fundamental manner (e.g., sent from the same source and sent to @@ -284,133 +269,176 @@ It is the opposite of packet-based, which treats each packet discretely (e.g., each packet is assessed individually to determine the action(s) to be taken). Flow-based NSF: A NSF that inspects network flows according to a set of policies intended for enforcing security properties. Flow- based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process. - I2NSF Agent: A software Component in a device that implements an - NSF. It receives provisioning information and requests for - operational data (e.g., monitoring data) from an I2NSF Consumer. - It is also responsible for enforcing the policies that it - receives from an I2NSF Consumer. - - I2NSF Action: An I2NSF Action is a special type of Action that is - used to control and monitor aspects of flow-based Network Security - Functions. Examples of I2NSF Actions include providing intrusion - detection and/or protection, web and flow filtering, and deep - packet inspection for packets and flows. An I2NSF Action, when - used in the context of a I2NSF Policy Rule, may be executed when - both the Event and the Condition clauses of its owning I2NSF - Policy Rule evaluate to true. The execution of this Action may be - influenced by applicable metadata. (from - [I-D.ietf-supa-generic-policy-info-model]). - - I2NSF Capability: A set of features that are available from an NSF - Server or an NSF Controller. While both are Capabilities, the - former defines functions that are available from an NSF, whereas - the latter defines functions that are available from a security - Controller or other Management Entity. This definition is based - on that in [I-D.ietf-sacm-terminology]. + I2NSF Action: An I2NSF Action is used to control and monitor + aspects of flow-based NSFs. An I2NSF Action, when used in the + context of an (imperative) I2NSF Policy Rule, may be executed + only when the Event and the Condition clauses of its owning + I2NSF Policy Rule evaluate to true. The execution of this I2NSF + Action may be influenced by applicable metadata. Examples of + I2NSF Actions include providing intrusion detection and/or + protection, web and flow filtering, and deep packet inspection + for packets and flows. + (based on [I-D.ietf-supa-generic-policy-info-model]). See also + I2NSF Condition, I2NSF Event, I2NSF Policy Rule. - I2NSF Client: See I2NSF Consumer. + I2NSF Agent: A software Component that implements an NSF. It + typically plays the roles of I2NSF Consumer and I2NSF Producer. + For example, it can receive provisioning information and requests + for operational and/or monitoring data from an I2NSF Component, + and can provide these and other data to I2NSF Consumers. It can + also receive I2NSF Policy Rules to change the configuration of + one or more network devices, optionally transform each I2NSF + Policy Rule into an alternate form (e.g., one that is directly + consummable by the network device), and then execute the I2NSF + Policy Rules. I2NSF Component: A Component that provides one or more I2NSF Services. I2NSF Components are managed and communicate with other I2NSF Components using I2NSF Interfaces. - I2NSF Consumer: A software Component that uses the I2NSF framework - to read, write, and/or change provisioning and operational aspects - of the NSFs that it attaches to. + I2NSF Condition: An I2NSF Condition is defined as a set of + attributes, features, and/or values that are to be compared with + a set of known attributes, features, and/or values in order to + determine whether or not the set of Actions in that (imperative) + I2NSF Policy Rule can be executed or not. An I2NSF Condition, + when used in the context of an (imperative) I2NSF Policy Rule, + may be executed only when the Event clause of its owning + I2NSF Policy Rule evaluates to true. Examples of an I2NSF + Condition include matching attributes of a packet or flow, and + comparing the internal state of an NSF to a desired state. + (based on [I-D.ietf-supa-generic-policy-info-model]). See also + I2NSF Action, I2NSF Event, I2NSF Policy Rule. - I2NSF Consumer Interface: An Interface dedicated to requesting and - using I2NSF Services. For example, this Interface could be used - to request a set of Flow Security policies from an I2NSF - Controller or from one or more individual NSFs. The difference is - that the former uses more abstract Condition matching (e.g., - based on tenant or customer ID), whereas the latter uses more - low-level Condition matching (e.g., based on flow state or fields - in a flow or packet). See also: Interface, I2NSF Provider - Interface, Client-Facing Interface, NSF-Facing Interface. + I2NSF Consumer: A Consumer is a Role that is assigned to an I2NSF + Component that contains functions to provide information to other + I2NSF Components. Examples include providing I2NSF Policy Rules + to other I2NSF Components. See also: I2NSF Consumer-Facing + Interface, I2NSF Producer, I2NSF Producer-Facing Interface, Role. - I2NSF Management System: I2NSF Consumers operate within the scope of - a network management system, which serves as a collection and - distribution point for I2NSF security provisioning. + I2NSF Consumer-Facing Interface: An Interface dedicated to + requesting information from I2NSF Producers. This is typically + defined per I2NSF administrative domain. For example, this + Interface could be used to request a set of I2NSF Flow Security + Policy Rules from an I2NSF Controller, or from one or more + individual NSFs. See also: I2NSF Consumer, I2NSF Provider, I2NSF + NSF-Facing Interface, Interface. - I2NSF Policy: A set of Policy Rules that are used to manage and - control the changing or maintaining of the state of an instance - of an NSF. + I2NSF Directly Consummable Policy Rule: An I2NSF Policy Rule is + said to be directly consummable if a network device can execute + it without translating its content or structure. See also I2NSF + Indirectly Consummable Policy Rule, I2NSF Policy Rule. - I2NSF Policy Rule: A Policy Rule that is adapted for I2NSF usage. - The I2NSF Policy Rule is assumed to be in ECA form (i.e., an - imperative structure). Other types of programming paradigms - (e.g., declarative and functional) are currently out of scope. - An example of an I2NSF Policy Rule is, in pseudo-code: + I2NSF Indirectly Consummable Policy Rule: An I2NSF Policy Rule is + said to be indirectly consummable if a network device can NOT + execute it without first translating its content or structure. See + also I2NSF Directly Consummable Policy Rule, I2NSF Policy Rule. + + I2NSF Event: An I2NSF Event is defined as any important occurrence + in time of a change in the system being managed, and/or in the + environment of the system being managed. An I2NSF Event, when used + in the context of an (imperative) I2NSF Policy Rule, is used to + determine whether the Condition clause of that Policy Rule can + be evaluated or not. Examples of an I2NSF Event include time and + user actions (e.g. logon, logoff, and actions that violate an + ACL). (based on [I-D.ietf-supa-generic-policy-info-model]). + See also I2NSF Action, I2NSF Condition, I2NSF Policy Rule. + + I2NSF Management System: I2NSF Consumers and Producers operate + within the scope of a network management system, which serves as + a collection and distribution point for I2NSF security + provisioning, monitoring, and other operations. + + I2NSF Policy Rule: An I2NSF Policy Rule is an imperative statement + that is used as a means to monitor and control the changing and/or + maintaining of the state of one or more managed objects. It + consists of three Boolean clauses (Event, Condition, and Action). + In this context, "manage" means that one or more of the following + six fundamental operations are supported: create, read, write, + delete, start, and stop). Note that for this release of I2NSF, + only imperative policy rules are in scope. An example of an I2NSF + Policy Rule is, in pseudo-code: IF is TRUE IF is TRUE THEN execute END-IF END-IF - In the above example, the Event, Condition, and Action portions - of a Policy Rule are all **Boolean Clauses**. + This is based on [I-D.draft-ietf-supa-generic-policy-info-model]. - I2NSF Provider Interface: An Interface dedicated to providing I2NSF - Services. For example, this could provide Anti-Virus, (D)DoS, or - IPS Services. See also: Interface, I2NSF Provider Interface, - Client-Facing Interface, NSF-Facing Interface. + I2NSF Producer: A Producer is a Role that is assigned to an I2NSF + Component that contains functions to send information and/or + commands to another I2NSF Component (e.g., for describing, + communicating, and/or executing policies, or for transmitting + data). See also: I2NSF Consumer, I2NSF Consumer-Facing Interface, + I2NSF Producer, I2NSF Producer-Facing Interface, Role. - I2NSF Registry: A registry that contains I2NSF capability - information, which can be controlled by the I2NSF Management - System. See also: Registry. + I2NSF Producer-Facing Interface: See NSF-Facing Interface. - I2NSF Service: A set of functions, provided by an I2NSF Consumer, - which are used by zero or more I2NSF Producers. Exemplary I2NSF - Services include Anti-Virus, Authentication, Authorization, - (D)DoS, Firewall, and IPS Services. See also: Interface, I2NSF - Provider Interface, Client-Facing Interface, NSF-Facing Interface. + I2NSF Registry: A repository where I2NSF data and metadata + information are stored and maintained. I2NSF Components can + connect to the I2NSF Registry using the I2NSF Registration + Interface; the actions that an I2NSF Component can performing + SHOULD be defined using an Access Control mechanism. Examples + of information that SHOULD be registered include Capability data, + as well as consistent defintions of data and I2NSF Components. + See also: Access Control, I2NSF Component, I2NSF Consumer, + I2NSF Provider, I2NSF Registration Interface. + + I2NSF Registration Interface: An Interface dedicated to + requesting information from, and writing information about, + I2NSF Components. See also: I2NSF Component, I2NSF Consumer, + I2NSF Provider, I2NSF Registry. + + I2NSF Service: A set of functions, provided by an I2NSF Component, + which provides data communication, processing, storage, + presentation, maniuplation, or other functions that can be + consumed by I2NSF Components. Exemplary I2NSF Services include + Anti-Virus, Authentication, Authorization, Firewall, and IPS + Services. See also: I2NSF Component, Interface. IDS: Intrusion Detection System (see below). IPS: Intrusion Protection System (see below). Information Model: A representation of concepts of interest to an environment in a form that is independent of data repository, data definition language, query language, implementation language, - and protocol [I-D.ietf-supa-generic-policy-info-model]. + and protocol. See also: Data Model. + (from [I-D.ietf-supa-generic-policy-info-model]). Interface: A set of operations one object knows it can invoke on, and expose to, another object. It is a subset of all operations that a given object implements. The same object may have multiple - types of interfaces to serve different purposes. An example of - multiple interfaces can be seen by considering the interfaces - include a firewall uses; these include: - - * multiple interfaces for data packets to traverse through, - * an interface for a controller to impose policy, or retrieve - the results of execution of a policy rule. - - See also: Consumer Interface, I2NSF Interface, Provider Interface + types of interfaces to serve different purposes. + See also: I2NSF Component, I2NSF Consumer-Facing Interface, I2NSF + Registration Interface, Interface Group, NSF-Facing Interface Interface Group: A set of Interfaces that are related in purpose and which share the same communication mechanisms. + See also: Interface. Intrusion Detection System (IDS): A system that detects network intrusions via a variety of filters, monitors, and/or probes. An - IDS may be stateful or stateless. + IDS may be stateful or stateless. See also: IPS. Intrusion Protection System (IPS): A system that protects against network intrusions. An IPS may be stateful or stateless. + See also: IDS. Management Plane: In the context of I2NSF, the Management Plane is an architectural Component that provides common functions to define the behavior of I2NSF Components. The primary use of the Management Plane is to transport behavioral commands, and supply OAM data, for making decisions that affect behavior. Examples include modifying the configuration of an I2NSF Component and transporting OAM data. See also: Control Plane, Data Plane. Metadata: Data that provides information about other data. @@ -424,135 +452,104 @@ datagram path between a source host and destination host [RFC3234]. Network Security Function (NSF): Software that provides a set of security-related services. Examples include detecting unwanted activity and blocking or mitigating the effect of such unwanted activity in order to fulfil service requirements. The NSF can also help in supporting communication stream integrity and confidentiality. - NSF-Facing Interface: An Interface dedicated to communication with - a set of NSFs. This is typically defined per I2NSF administrative - domain. See also: Interface, Consumer-Facing Interface. - - OAM: Operation, Administrative, and Management. + NSF-Facing Interface: An Interface dedicated to specifying and + monitoring I2NSF Policy Rules that are enforced by one or more + NSFs. This is typically defined per I2NSF administrative + domain. Note that all features of a given NSF do not have to be + used. See also: Consumer-Facing Interface, Interface. - OCL (Object Constraint Language): A constraint programming language - that is used to specify constraints (e.g., in UML) (from + Object Constraint Language (OCL): A constraint programming language + that is used to specify restrictions on functionality. (from http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) - Policy Rule: A set of rules that are used to manage and control - the changing or maintaining of the state of one or more managed - objects. Often this is shortened to Rule or Policy (see I2NSF - policy rule). (from [I-D.ietf-supa-generic-policy-info-model]). - Profile: A structured representation of information that uses a pre-defined set of capabilities of an object, typically in a specific context. Zero or more Capabilities may be changed at runtime. This may be used to simplify how this object interacts with other objects in its environment. - Producer: A Producer is a Role that is assigned to an I2NSF - Component that can send information and/or commands to another - I2NSF Component. See also: Consumer, Role. - - Registry: A logically centralized location containing data of a - particular type; it may optionally contain metadata, - relationships, and other aspects of the registered data in order - to use those data effectively. An I2NSF registry is used to - contain capability information that can be controlled by the - controller. - - Registration Interface: An interface dedicated to requesting, - receiving, editing, and deleting information in a Registry. - Role: An abstraction of a Component that models context-specific views and responsibilities of an object as separate Role objects. Role objects can optionally be attached to, and removed from, the object that the Role object describes at runtime. This provides three important benefits. First, it enables different behavior to be supported by the same Component for different contexts. Second, it enables the behavior of a Component to be adjusted dynamically (i.e., at runtime, in response to changes in context) by using one or more Roles to define the behavior desired for each context. Third, it decouples the Roles of a Component from the Applications use that Component. - Service Interface: An Interface dedicated to enabling Policy Rules - to be managed. This is also called the I2NSF Consumer Interface. - - Service Provider Security Controller: TBD (Editorial: Place holder - for a split between controller and security controller - definitions.) - Tenant: A group of users that share common access privileges to the same software. An I2NSF tenant may be physical or virtual, and may run on a variety of systems or servers. - Vendor-Facing Interface: An Interface dedicated to registering and - vendor-specific NSFs and Capabilities. It is also used to invoke - vendor-specific functionality. This is also called the NSF-Facing - Interface. - 3. IANA Considerations No IANA considerations exist for this document. 4. Security Considerations This is a terminology document with no security considerations. 5. Contributors The following people contributed to creating this document, and are listed in alphabetical order: - Henk Birkholz + Adrian Farrel, Linda Dunbar 6. References 6.1. Informative References [I-D.ietf-i2nsf-gap-analysis] Hares, S., Moskowitz, R., and Zhang, D., "Analysis of - Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-02 - (work in progress), July 2016. + Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03 + (work in progress), March 2017. [I-D.ietf-i2nsf-problem-and-use-cases] Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. Jacquenet, "I2NSF Problem Statement and Use cases", draft- - ietf-i2nsf-problem-and-use-cases-02 (work in progress), - October 2016. + ietf-i2nsf-problem-and-use-cases-09 (work in progress), + February 2017. [I-D.ietf-netmod-acl-model] Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., "Network Access Control List (ACL) YANG Data Model", draft-ietf-netmod-acl-model-09 (work in progress), - October 2016. + February 2017. [I-D.ietf-opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", draft-ietf-opsawg-firewalls-01 (work in progress), October 2012. [I-D.ietf-sacm-terminology] Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N., "Secure Automation and Continuous Monitoring (SACM) Terminology", draft-ietf-sacm-terminology-11, September 2016 [I-D.ietf-supa-generic-policy-info-model] Strassner, J., Halpern, J., and J. Coleman, "Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)", draft-ietf-supa-generic-policy- - info-model-01 (work in progress), July 2016. + info-model-02 (work in progress), January 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, . [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,