idnits 2.17.1 draft-ietf-i2nsf-terminology-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 62 lines 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 date (July 03, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-11 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-12 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF S. Hares 2 Internet-Draft J. Strassner 3 Intended status: Informational Huawei 4 Expires: January 07, 2018 D. Lopez 5 Telefonica I+D 6 L. Xia 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 July 03, 2017 12 Interface to Network Security Functions (I2NSF) Terminology 13 draft-ietf-i2nsf-terminology-04.txt 15 Abstract 17 This document defines a set of terms that are used for the Interface 18 to Network Security Functions (I2NSF) effort. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current 28 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 This Internet-Draft will expire on January 07, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided 51 without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6.1. Informative References . . . . . . . . . . . . . . . . . 12 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 64 1. Introduction 66 This document defines the terminology for the Interface to Network 67 Security Functions (I2NSF) effort. This section provides some 68 background on I2NSF; a detailed problem statement can be found in 69 [I-D.ietf-i2nsf-problem-and-use-cases]. Motivation and comparison to 70 previous work can be found in [I-D.ietf-i2nsf-gap-analysis]. 72 Enterprises are now considering using network security functions 73 (NSFs) hosted by service providers due to the growing challenges and 74 complexity in maintaining an up-to-date secure infrastructure that 75 complies with regulatory requirements, while controlling costs. The 76 hosted security service is especially attractive to small- and 77 medium-size enterprises who suffer from a lack of security experts 78 to continuously monitor, acquire new skills and propose immediate 79 mitigations to ever increasing sets of security attacks. Small- and 80 medium-sized businesses (SMBs) are increasingly adopting cloud-based 81 security services to replace on-premises security tools, while larger 82 enterprises are deploying a mix of traditional (hosted) and cloud- 83 based security services. 85 To meet the demand, more and more service providers are providing 86 hosted security solutions to deliver cost-effective managed security 87 services to enterprise customers. The hosted security services are 88 primarily targeted at enterprises, but could also be provided to 89 mass-market customers as well. NSFs are provided and consumed in 90 increasingly diverse environments. Users of NSFs may consume 91 network security services hosted by one or more providers, which 92 may be their own enterprise, service providers, or a combination 93 of both. 95 It is out of scope in this document to define an exhaustive list of 96 terms that are used in the security field; the reader is referred to 97 other applicable documents, such as [RFC4949]. 99 2. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in [RFC2119]. In 104 this document, these words will appear with that interpretation 105 only when in ALL CAPS. Lower case uses of these words are not to 106 be interpreted as carrying [RFC2119] significance. 108 3. Terminology 110 AAA: Authentication, Authorization, and Accounting. See individual 111 definitions. 113 Abstraction: The definition of the salient characteristics and 114 behavior of an object that distinguish it from all other types of 115 objects. It manages complexity by exposing common properties 116 between objects and processes while hiding detail that is not 117 relevant. 119 Access Control: Protection of system resources against unauthorized 120 access; a process by which use of system resources is regulated 121 according to a security policy, and is permitted by only 122 authorized entities (e.g., users, programs, processes, or other 123 systems) according to that policy [RFC4949]. 125 Access Control List (ACL): This is a mechanism that implements 126 access control for a system resource by enumerating the system 127 entities that are permitted to access the resource and stating, 128 either implicitly or explicitly, the access modes granted to each 129 entity [RFC4949]. A YANG description is defined in 130 [I-D.ietf-netmod-acl-model]. 132 Accounting: The act of collecting information on resource usage for 133 the purpose of trend analysis, auditing, billing, or cost 134 allocation ([RFC2975] [RFC3539]). 136 Assertion: Defined by the ITU in [X.1252] as "a statement made by 137 an entity without accompanying evidence of its validity". In the 138 context of I2NSF, an assertion may include metadata about all or 139 part of the assertion (e.g., context of the assertion, or about 140 timestamp indicating the point in time the assertion was 141 created). The validity of an assertion cannot be verified. 142 (from [I-D.ietf-sacm-terminology]). 144 Attestation: The process of validating the integrity of a computing 145 device. See also Direct Anonymous Attestation, Remote Attestation. 147 Authentication: Defined in [RFC4949] as "the process of verifying 148 a claim that a system entity or system resource has a certain 149 attribute value." (from [I-D.ietf-sacm-terminology]). 151 Authorization: Defined in [RFC4949] as "an approval that is granted 152 to a system entity to access a system resource." 153 (from [I-D.ietf-sacm-terminology]). 155 Business-to-Business (B2B). A type of transaction in which one 156 business makes a commercial transaction with another business. 158 Business-to-Consumer (B2C). A type of transaction in which a 159 business makes a commercial transaction with a Customer. 161 Bespoke: Something made to fit a particular person, customer, or 162 company. 164 Bespoke security management: Security management systems that are 165 made to fit a particular customer. 167 Boolean Clause: A logical statement that evaluates to either TRUE 168 or FALSE. Also called Boolean Expression. 170 Capability: A set of features that are available from an I2NSF 171 Component. These functions may, but do not have to, be used. All 172 Capabilities are announced using the I2NSF Registration 173 Interface. 175 Component: An encapsulation of software that communicates using 176 Interfaces. A Component may be implemented by hardware and/or 177 software, and be represented using a set of classes. In general, 178 a Component encapsulates a set of data structures and a set of 179 algorithms that implement the function(s) that it provides. 181 Constraint: A Constraint is a limitation or restriction. 182 Constraints may be associated with any type of object (e.g., 183 Events, Conditions, and Actions in Policy Rules). 185 Constraint Programming: A type of programming that uses constraints 186 to define relations between variables in order to find a 187 feasible (and not necessarily optimal) solution. 189 Context: The Context of an Entity is a collection of measured and/ 190 or inferred knowledge that describe the state and the environment 191 in which an Entity exists or has existed. (from 192 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html). 194 Controller: A Controller is a management Component that contains 195 control plane functions to manage and facilitate information 196 sharing, as well as execute security functions. This definition 197 is based on that in [I-D.ietf-sacm-terminology]. 199 Control Plane: In the context of I2NSF, the Control Plane is an 200 architectural Component that provides common control functions 201 to all I2NSF Components, including some or all of the following: 202 authentication, authorization, accounting, auditing, and 203 Capability discovery and negotiation. The Control Plane 204 orchestrates the operation of the Data Plane according to 205 guidance and/or input from the Management Plane. I2NSF Components 206 with Interfaces to the Control Plane have knowledge of the 207 Capabilities of other I2NSF Components within a particular I2NSF 208 administrative domain. This definition is based on that in 209 [I-D.ietf-sacm-terminology]. See also: Data Plane, Management 210 Plane. 212 Customer: A business role of an entity that is involved in the 213 definition and/or consumption of services, and the possible 214 negotiation of a contract to use services from a Provider. 216 Data Center (DC): A facility used to house data processing and 217 communication equipment. 219 Data Confidentiality: Defined in [RFC4949] as "the property that 220 data is not disclosed to system entities unless they have been 221 authorized to know the data." 223 Data Integrity: Defined in [RFC4949] as "the property that data has 224 not been changed, destroyed, or lost in an unauthorized or 225 accidental manner." 227 Data Model: A representation of concepts of interest to an 228 environment in a form that is dependent on data repository, data 229 definition language, query language, implementation language, and 230 protocol (typically one or more of these ). Note the difference 231 between a data **model** and a data **structure**. 232 [I-D.ietf-supa-generic-policy-data-model]. 234 Data Plane: In the context of I2NSF, the Data Plane is an 235 architectural Component that provides operational functions to 236 enable an I2NSF Component to provide and consume packets and 237 flows. See also: Control Plane, Management Plane. 239 Data Provenance: A historical record of the sources, origins and 240 evolution of data that is influenced by inputs, entities, 241 functions and processes. 243 Data Structure: A low-level building block that is used in 244 programming to implement an algorithm. It defines how data is 245 organized. A data model typically contains multiple types of 246 data structures; however, a data structure does not contain a 247 data model. Note the difference between a data **model** and a 248 data **structure**. 250 Domain: A collection of Entities that share a common purpose. In 251 addition, each constituent Entity in a Domain is both uniquely 252 addressable and uniquely identifiable within that Domain. 254 Direct Anonymous Attestation (DAA): A cryptographic primitive that 255 enables remote authentication of a trusted computer without 256 compromising the privacy of that computer's user(s). See also 257 attestation, remote attestation. 259 Firewall (FW): A function that restricts data communication traffic 260 to and from one of the connected networks (the one said to be 261 'inside' the firewall), and thus protects that network's system 262 resources against threats from the other network (the one that 263 is said to be 'outside' the firewall) [RFC4949]. 264 [I-D.ietf-opsawg-firewalls] 266 Flow: A set of information (e.g., packets) that are related in a 267 fundamental manner (e.g., sent from the same source and sent to 268 the same destination). A common example is a sequence of packets. 269 It is the opposite of packet-based, which treats each packet 270 discretely (e.g., each packet is assessed individually to 271 determine the action(s) to be taken). 273 Flow-based NSF: A NSF that inspects network flows according to a 274 set of policies intended for enforcing security properties. Flow- 275 based security also means that packets are inspected in the order 276 they are received, and without modification to the packet due to 277 the inspection process. 279 I2NSF Action: An I2NSF Action is used to control and monitor 280 aspects of flow-based NSFs. An I2NSF Action, when used in the 281 context of an (imperative) I2NSF Policy Rule, may be executed 282 only when the Event and the Condition clauses of its owning 283 I2NSF Policy Rule evaluate to true. The execution of this I2NSF 284 Action may be influenced by applicable metadata. Examples of 285 I2NSF Actions include providing intrusion detection and/or 286 protection, web and flow filtering, and deep packet inspection 287 for packets and flows. 288 (based on [I-D.ietf-supa-generic-policy-info-model]). See also 289 I2NSF Condition, I2NSF Event, I2NSF Policy Rule. 291 I2NSF Agent: A software Component that implements an NSF. It 292 typically plays the roles of I2NSF Consumer and I2NSF Producer. 293 For example, it can receive provisioning information and requests 294 for operational and/or monitoring data from an I2NSF Component, 295 and can provide these and other data to I2NSF Consumers. It can 296 also receive I2NSF Policy Rules to change the configuration of 297 one or more network devices, optionally transform each I2NSF 298 Policy Rule into an alternate form (e.g., one that is directly 299 consummable by the network device), and then execute the I2NSF 300 Policy Rules. 302 I2NSF Component: A Component that provides one or more I2NSF 303 Services. I2NSF Components are managed and communicate with other 304 I2NSF Components using I2NSF Interfaces. 306 I2NSF Condition: An I2NSF Condition is defined as a set of 307 attributes, features, and/or values that are to be compared with 308 a set of known attributes, features, and/or values in order to 309 determine whether or not the set of Actions in that (imperative) 310 I2NSF Policy Rule can be executed or not. An I2NSF Condition, 311 when used in the context of an (imperative) I2NSF Policy Rule, 312 may be executed only when the Event clause of its owning 313 I2NSF Policy Rule evaluates to true. Examples of an I2NSF 314 Condition include matching attributes of a packet or flow, and 315 comparing the internal state of an NSF to a desired state. 316 (based on [I-D.ietf-supa-generic-policy-info-model]). See also 317 I2NSF Action, I2NSF Event, I2NSF Policy Rule. 319 I2NSF Consumer: A Consumer is a Role that is assigned to an I2NSF 320 Component that contains functions to provide information to other 321 I2NSF Components. Examples include providing I2NSF Policy Rules 322 to other I2NSF Components. See also: I2NSF Consumer-Facing 323 Interface, I2NSF Producer, I2NSF Producer-Facing Interface, Role. 325 I2NSF Consumer-Facing Interface: An Interface dedicated to 326 requesting information from I2NSF Producers. This is typically 327 defined per I2NSF administrative domain. For example, this 328 Interface could be used to request a set of I2NSF Flow Security 329 Policy Rules from a Controller, or from one or more 330 individual NSFs. See also: I2NSF Consumer, I2NSF Provider, 331 I2NSF NSF-Facing Interface, Interface. 333 I2NSF Directly Consummable Policy Rule: An I2NSF Policy Rule is 334 said to be directly consummable if a network device can execute 335 it without translating its content or structure. See also I2NSF 336 Indirectly Consummable Policy Rule, I2NSF Policy Rule. 338 I2NSF Indirectly Consummable Policy Rule: An I2NSF Policy Rule is 339 said to be indirectly consummable if a network device can NOT 340 execute it without first translating its content or structure. See 341 also I2NSF Directly Consummable Policy Rule, I2NSF Policy Rule. 343 I2NSF Event: An I2NSF Event is defined as any important occurrence 344 in time of a change in the system being managed, and/or in the 345 environment of the system being managed. An I2NSF Event, when used 346 in the context of an (imperative) I2NSF Policy Rule, is used to 347 determine whether the Condition clause of that Policy Rule can 348 be evaluated or not. Examples of an I2NSF Event include time and 349 user actions (e.g. logon, logoff, and actions that violate an 350 ACL). (based on [I-D.ietf-supa-generic-policy-info-model]). 351 See also I2NSF Action, I2NSF Condition, I2NSF Policy Rule. 353 I2NSF Management System: I2NSF Consumers and Producers operate 354 within the scope of a network management system, which serves as 355 a collection and distribution point for I2NSF security 356 provisioning, monitoring, and other operations. 358 I2NSF NSF-Facing Interface: An Interface dedicated to providing I2NSF 359 Services. For example, this could provide Anti-Virus, (D)DoS, or 360 IPS Services. This is also called the "NSF-Facing Interface". 361 See also: Interface, I2NSF Consumer Interface. 363 I2NSF Policy Rule: An I2NSF Policy Rule is an imperative statement 364 that is used as a means to monitor and control the changing and/or 365 maintaining of the state of one or more managed objects. It 366 consists of three Boolean clauses (Event, Condition, and Action). 367 In this context, "manage" means that one or more of the following 368 six fundamental operations are supported: create, read, write, 369 delete, start, and stop). Note that for this release of I2NSF, 370 only imperative policy rules are in scope. An example of an I2NSF 371 Policy Rule is, in pseudo-code: 373 IF is TRUE 374 IF is TRUE 375 THEN execute 376 END-IF 377 END-IF 379 This is based on [I-D.ietf-supa-generic-policy-info-model]. 381 I2NSF Producer: A Producer is a Role that is assigned to an I2NSF 382 Component that contains functions to send information and/or 383 commands to another I2NSF Component (e.g., for describing, 384 communicating, and/or executing policies, or for transmitting 385 data). See also: I2NSF Consumer, I2NSF Consumer-Facing Interface, 386 I2NSF Producer, I2NSF Producer-Facing Interface, Role. 388 I2NSF Registry: A repository where I2NSF data and metadata 389 information are stored and maintained. I2NSF Components can 390 connect to the I2NSF Registry using the I2NSF Registration 391 Interface; the actions that an I2NSF Component can performing 392 SHOULD be defined using an Access Control mechanism. Examples 393 of information that SHOULD be registered include Capability data, 394 as well as consistent defintions of data and I2NSF Components. 395 See also: Access Control, I2NSF Component, I2NSF Consumer, 396 I2NSF Provider, I2NSF Registration Interface. 398 I2NSF Registration Interface: An Interface dedicated to 399 requesting information from, and writing information about, 400 I2NSF Components. See also: I2NSF Component, I2NSF Consumer, 401 I2NSF Provider, I2NSF Registry. 403 I2NSF Service: A set of functions, provided by an I2NSF Component, 404 which provides data communication, processing, storage, 405 presentation, maniuplation, or other functions that can be 406 consumed by I2NSF Components. Exemplary I2NSF Services include 407 Anti-Virus, Authentication, Authorization, Firewall, and IPS 408 Services. See also: I2NSF Component, Interface. 410 Information Model: A representation of concepts of interest to an 411 environment in a form that is independent of data repository, 412 data definition language, query language, implementation language, 413 and protocol. See also: Data Model. 414 (from [I-D.ietf-supa-generic-policy-info-model]). 416 Interface: A set of operations one object knows it can invoke on, 417 and expose to, another object. It is a subset of all operations 418 that a given object implements. The same object may have multiple 419 types of interfaces to serve different purposes. 420 See also: I2NSF Component, I2NSF Consumer-Facing Interface, I2NSF 421 Registration Interface, Interface Group, NSF-Facing Interface 423 Interface Group: A set of Interfaces that are related in purpose and 424 which share the same communication mechanisms. 425 See also: Interface. 427 Intrusion Detection System (IDS): A system that detects network 428 intrusions via a variety of filters, monitors, and/or probes. An 429 IDS may be stateful or stateless. See also: IPS. 431 Intrusion Protection System (IPS): A system that protects against 432 network intrusions. An IPS may be stateful or stateless. 433 See also: IDS. 435 Management Domain: A collection Entities that share a common 436 purpose, which has the following three behavioral features: 437 1) a set of administrators are assigned to govern the Entities 438 that are contained in a Management Domain 439 2) a set of application are defined that are responsible for 440 executing one or more governance operations 441 3) a set of management mechanisms, such as Policy Rules, are 442 defined to govern the behavior of the Entities contained 443 in the Mangement Domain. 445 Management Plane: In the context of I2NSF, the Management Plane is 446 an architectural Component that provides common functions to 447 define the behavior of I2NSF Components. The primary use of the 448 Management Plane is to formulate behavioral commands and forward 449 them to the Control Plane. The Control Plane then translates them 450 into a form that can be consumed by I2NSF components. The 451 Management Plane may also instantiate and manage I2NSF Policy 452 Rules. The Management Plane is also responsible for handling and 453 acting on OAM data, which may influence the decision-making 454 processes in the I2NSF Control Plane and other I2NSF Components. 455 See also: Control Plane, Data Plane. 457 Metadata: Data that provides information about other data. 458 Examples include IETF network management protocols (e.g. NETCONF, 459 RESTCONF, IPFIX) or IETF routing interfaces (I2RS). The I2NSF 460 security interface may utilize Metadata to describe and/or 461 prescribe characteristics and behavior of the YANG data models. 463 Middlebox: Any intermediary device performing functions other 464 than the normal, standard functions of an IP router on the 465 datagram path between a source host and destination host 466 [RFC3234]. 468 Network Security Function (NSF): Software that provides a set of 469 security-related services. Examples include detecting unwanted 470 activity and blocking or mitigating the effect of such unwanted 471 activity in order to fulfil service requirements. The NSF can 472 also help in supporting communication stream integrity and 473 confidentiality. 475 NSF-Facing Interface: An Interface dedicated to specifying and 476 monitoring I2NSF Policy Rules that are enforced by one or more 477 NSFs. This is typically defined per I2NSF administrative 478 domain. Note that all features of a given NSF do not have to be 479 used. See also: Consumer-Facing Interface, Interface. 481 Object Constraint Language (OCL): A constraint programming language 482 that is used to specify restrictions on functionality. (from 483 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) 485 Profile: A structured representation of information that uses a 486 pre-defined set of capabilities of an object, typically in a 487 specific context. Zero or more Capabilities may be changed at 488 runtime. This may be used to simplify how this object interacts 489 with other objects in its environment. 491 Remote Attestation: A functoin that enables changes to an Entity to 492 be detected by authorized parties (e.g., applications or users). 493 Direct Anonymous Attestation preserves the privacy of the user, 494 whereas remote attestation may not. See also: Attestation, 495 Direct Anonymous Attestation. 497 Role: An abstraction of a Component that models context-specific 498 views and responsibilities of an object as separate Role objects. 499 Role objects can optionally be attached to, and removed from, the 500 object that the Role object describes at runtime. This provides 501 three important benefits. First, it enables different behavior 502 to be supported by the same Component for different contexts. 503 Second, it enables the behavior of a Component to be adjusted 504 dynamically (i.e., at runtime, in response to changes in context) 505 by using one or more Roles to define the behavior desired for 506 each context. Third, it decouples the Roles of a Component from 507 the Applications use that Component. 509 Tenant: A group of users that share common access privileges to 510 the same software. An I2NSF tenant may be physical or virtual, 511 and may run on a variety of systems or servers. 513 3. IANA Considerations 515 No IANA considerations exist for this document. 517 4. Security Considerations 519 This is a terminology document with no security considerations. 521 5. Contributors 523 The following people contributed to creating this document, and are 524 listed in alphabetical order: 526 Adrian Farrel, Christian Jacquenet, Linda Dunbar, 527 Mohammed Boucadair 529 6. References 530 6.1. Informative References 532 [I-D.ietf-i2nsf-gap-analysis] 533 Hares, S., Moskowitz, R., and Zhang, D., "Analysis of 534 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03 535 (work in progress), March 2017. 537 [I-D.ietf-i2nsf-problem-and-use-cases] 538 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 539 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 540 ietf-i2nsf-problem-and-use-cases-16 (work in progress), 541 May 2017. 543 [I-D.ietf-netmod-acl-model] 544 Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., 545 "Network Access Control List (ACL) YANG Data Model", 546 draft-ietf-netmod-acl-model-11 (work in progress), 547 June 2017. 549 [I-D.ietf-opsawg-firewalls] 550 Baker, F. and P. Hoffman, "On Firewalls in Internet 551 Security", draft-ietf-opsawg-firewalls-01 (work in 552 progress), October 2012. 554 [I-D.ietf-sacm-terminology] 555 Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N., 556 "Secure Automation and Continuous Monitoring (SACM) 557 Terminology", draft-ietf-sacm-terminology-12, 558 March 2017 560 [I-D.ietf-supa-generic-policy-data-model] 561 Strassner, J., Halpern, J., and S. van der Meer, "Generic 562 Policy Data Model for Simplified Use of Policy 563 Abstractions (SUPA)", draft-ietf-supa-generic-policy- 564 data-model-04 (work in progress), June 2017. 566 [I-D.ietf-supa-generic-policy-info-model] 567 Strassner, J., Halpern, J., and S. van der Meer, "Generic 568 Policy Information Model for Simplified Use of Policy 569 Abstractions (SUPA)", draft-ietf-supa-generic-policy- 570 info-model-03 (work in progress), May 2017. 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 576 Accounting Management", RFC 2975, DOI 10.17487/RFC2975, 577 October 2000, . 579 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 580 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 581 . 583 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 584 Accounting (AAA) Transport Profile", RFC 3539, 585 DOI 10.17487/RFC3539, June 2003, 586 . 588 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 589 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 590 . 592 [X.1252] ITU-T, "Baseline identity management terms and 593 definitions", Recommendation ITU-T X.1252, April 2510 595 Authors' Addresses 597 Susan Hares 598 Huawei 599 7453 Hickory Hill 600 Saline, MI USA 48176 601 Phone: +1-734-604-0332 602 Email: shares@ndzh.com 604 John Strassner 605 Huawei Technologies 606 Santa Clara, CA USA 95050 607 Email: john.sc.strassner@huawei.com 609 Diego R. Lopez 610 Telefonica I+D 611 Don Ramon de la Cruz, 82 612 Madrid 28006 613 Spain 614 Email: diego.r.lopez@telefonica.com 616 Liang Xia (Frank) 617 Huawei 618 101 Software Avenue, Yuhuatai District 619 Nanjing , Jiangsu 210012 620 China 621 Email: Frank.Xialiang@huawei.com 623 Henk Birkholz 624 Fraunhofer SIT 625 Rheinstrasse 75 626 Darmstadt 64295 627 Germany 628 Email: henk.birkholz@sit.fraunhofer.de