idnits 2.17.1 draft-ietf-i2nsf-terminology-01.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 date (July 8, 2016) is 2847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-i2nsf-gap-analysis-01 == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-01 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-08 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-09 == Outdated reference: A later version (-03) exists of draft-ietf-supa-generic-policy-info-model-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF S. Hares 3 Internet-Draft J. Strassner 4 Intended status: Informational Huawei 5 Expires: January 29, 2017 D. Lopez 6 Telefonica I+D 7 L. Xia 8 Huawei 9 July 8, 2016 11 Interface to Network Security Functions (I2NSF) Terminology 12 draft-ietf-i2nsf-terminology-01.txt 14 Abstract 16 This document defines a set of terms that are used for the Interface 17 to Network Security Functions (I2NSF) effort. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current 27 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 This Internet-Draft will expire on January 29, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided 50 without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6.1. Informative References . . . . . . . . . . . . . . . . . 11 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 63 1. Introduction 65 This document defines the terminology for the Interface to Network 66 Security Functions (I2NSF) effort. This section provides some 67 background on I2NSF; a detailed problem statement can be found in 68 [I-D.ietf-i2nsf-problem-and-use-cases]. Motivation and comparison to 69 previous work can be found in [I-D.ietf-i2nsf-gap-analysis]. 71 Enterprises are now considering using network security functions 72 (NSFs) hosted by service providers due to the growing challenges and 73 complexity in maintaining an up-to-date secure infrastructure that 74 complies with regulatory requirements, while controlling costs. The 75 hosted security service is especially attractive to small- and 76 medium-size enterprises who suffer from a lack of security experts 77 to continuously monitor, acquire new skills and propose immediate 78 mitigations to ever increasing sets of security attacks. Small- and 79 medium-sized businesses (SMBs) are increasingly adopting cloud-based 80 security services to replace on-premises security tools, while larger 81 enterprises are deploying a mix of traditional (hosted) and cloud- 82 based security services. 84 To meet the demand, more and more service providers are providing 85 hosted security solutions to deliver cost-effective managed security 86 services to enterprise customers. The hosted security services are 87 primarily targeted at enterprises, but could also be provided to 88 mass-market customers as well. NSFs are provided and consumed in 89 increasingly diverse environments. Users of NSFs may consume 90 network security services hosted by one or more providers, which 91 may be their own enterprise, service providers, or a combination 92 of both. 94 It is out of scope in this document to define an exhaustive list of 95 terms that are used in the security field; the reader is referred to 96 other applicable documents, such as [RFC4949]. 98 2. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 102 this document are to be interpreted as described in [RFC2119]. In 103 this document, these words will appear with that interpretation 104 only when in ALL CAPS. Lower case uses of these words are not to 105 be interpreted as carrying [RFC2119] significance. 107 3. Terminology 109 AAA: Authentication, Authorization, and Accounting. See individual 110 definitions. 112 Abstraction: The definition of the salient characteristics and 113 behavior of an object that distinguish it from all other types of 114 objects. It manages complexity by exposing common properties 115 between objects and processes while hiding detail that is not 116 relevant. 118 Access Control: Protection of system resources against unauthorized 119 access; a process by which use of system resources is regulated 120 according to a security policy, and is permitted by only 121 authorized entities (users, programs, processes, or other systems) 122 according to that policy [RFC4949]. 124 Accounting: The act of collecting information on resource usage for 125 the purpose of trend analysis, auditing, billing, or cost 126 allocation ([RFC2975] [RFC3539]). 128 ACL (Acess Control List): This is a mechanism that implements 129 access control for a system resource by enumerating the system 130 entities that are permitted to access the resource and stating, 131 either implicitly or explicitly, the access modes granted to each 132 entity [RFC4949]. A YANG description is defined in 133 [I-D.ietf-netmod-acl-model]. 135 Action: Defines what is to be done when a set of Conditions are 136 met (See I2NSF Action). (from 137 [I-D.ietf-supa-generic-policy-info-model]). 139 Assertion: Defined by the ITU in [X.1252] as "a statement made by 140 an entity without accompanying evidence of its validity". In the 141 context of I2NSF, an assertion MAY include metadata about all or 142 part of the assertion (e.g., context of the assertion, or about 143 timestamp indicating the point in time the assertion was 144 created). The validity of an assertion cannot be verified. 145 (from [I-D.ietf-sacm-terminology]). 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 B2B: Business-to-Business. 157 Bespoke: Something made to fit a particular person, customer, or 158 company. 160 Bespoke security management: Security management systems that are 161 make to fit a particular customer. 163 Boolean Clause: A logical statement that evaluates to either TRUE 164 or FALSE. Also called Boolean Expression. 166 Capability: Defines a set of features that are available from a 167 managed entity (see also I2NSF Capability). Examples of "managed 168 entities" are NSFs and Controllers, where NSF Capabilities and 169 Controller Capabilities define functionality of an NSF and about 170 Controller, respectively. These functions may, but do not have 171 to, be used. All Capabilities are announced through the 172 Registration Interface. 174 Capability Interface: An interface dedicated to requesting, 175 receiving, editing, and deleting capability information. 177 Client: See Consumer. [Editor's note: placeholder for gradually 178 replacing Client with Consumer, since Client is too vague and 179 has other connotations (e.g., client-server)]. 181 Client-Facing Interface: See Consumer-Facing Interface. 182 See also: Interface, NSF-Facing Interface. 184 Component: An encapsulation of software that communicates using 185 Interfaces. A Component may be implemented by hardware and/or 186 software, and be represented using a set of classes. In general, 187 a Component encapsulates a set of data structures and a set of 188 algorithms that implement the function(s) that it provides. 190 Consumer: A Consumer is a Role that is assigned to an I2NSF 191 Component that can receive information from another I2NSF 192 Component. See also: Provider, Role. 194 Consumer-Facing Interface: An Interface dedicated to communication 195 with Consumers of NSF data and Services. This is typically 196 defined per I2NSF administrative domain. See also: Interface, 197 NSF-Facing Interface. 199 Condition: A set of attributes, features, and/or values that are to 200 be compared with a set of known attributes, features, and/or 201 values in order to make a decision. A Condition, when used in the 202 context of a Policy Rule, is used to determine whether or not the 203 set of Actions in that Policy Rule can be executed or not. 204 Examples of an I2NSF Condition include matching attributes of a 205 packet or flow, and comparing the internal state of a NSF to a 206 desired state. (from [I-D.ietf-supa-generic-policy-info-model]). 208 Constraint: A Constraint is a limitation or restriction. 209 Constraints may be associated with any type of object (e.g., 210 Events, Conditions, and Actions in Policy Rules). 212 Constraint Programming: A type of programming that uses constraints 213 to define relations between variables in order to find a 214 feasible (and not necessarily optimal) solution. 216 Context: The Context of an Entity is a collection of measured and/ 217 or inferred knowledge that describe the state and the environment 218 in which an Entity exists or has existed. (from 219 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html). 221 Controller: A Controller is a management Component that contains 222 control plane functions to manage and facilitate information 223 sharing, as well as execute security functions. This definition 224 is based on that in [I-D.ietf-sacm-terminology]. 226 Control Plane: In the context of I2NSF, the Control Plane is an 227 architectural Component that provides common control functions 228 to all I2NSF Components, including some or all of the following: 229 authentication, authorization, accounting, auditing, and 230 Capability discovery and negotiation. The Control Plane 231 orchestrates the operation of the Data Plane according to 232 guidance and/or input from the Management Plane. I2NSF Components 233 with Interfaces to the Control Plane have knowledge of the 234 Capabilities of other I2NSF Components within a particular I2NSF 235 administrative domain. This definition is based on that in 236 [I-D.ietf-sacm-terminology]. See also: Data Plane, Management 237 Plane. 239 Customer: A business role of an entity that is involved in the 240 definition and/or consumption of services, and the possible 241 negotiation of a contract to use services from a Provider. 243 DC: Data Center 244 Data Model: A representation of concepts of interest to an 245 environment in a form that is dependent on data repository, data 246 definition language, query language, implementation language, and 247 protocol (typically one or more of these ). Note the difference 248 between a data **model** and a data **structure**. 249 [I-D.ietf-supa-generic-policy-info-model]. 251 Data Plane: In the context of I2NSF, the Data Plane is an 252 architectural Component that provides operational functions to 253 enable an I2NSF Component to provide and consume packets and 254 flows. See also: Control Plane, Management Plane. 256 Data Structure: A low-level building block that is used in 257 programming to implement an algorithm. A data model typically 258 contains multiple types of data structures; however, a data 259 structure does not contain a data model. Note the difference 260 between a data **model** and a data **structure**. 262 Event: An important occurrence in time of a change in the system 263 being managed, and/or in the environment of the system being 264 managed. Examples of an I2NSF Event include time and user actions 265 (e.g. logon, logoff, and actions that violate an ACL). An Event, 266 when used in the context of a Policy Rule, is used to determine 267 whether the Condition clause of an imperative Policy Rule can be 268 evaluated or not (from [I-D.ietf-supa-generic-policy-info-model]). 270 ECA: Event - Condition - Action (a type of Policy Rule). 272 Firewall (FW): A function that restricts data communication traffic 273 to and from one of the connected networks (the one said to be 274 'inside' the firewall), and thus protects that network's system 275 resources against threats from the other network (the one that 276 is said to be 'outside' the firewall) [RFC4949]. 277 [I-D.ietf-opsawg-firewalls] 279 Flow-based NSF: A NSF that inspects network flows according to a 280 set of policies intended for enforcing security properties. Flow- 281 based security also means that packets are inspected in the order 282 they are received, and without modification to the packet due to 283 the inspection process. 285 I2NSF Action: An I2NSF Action is a special type of Action that is 286 used to control and monitor aspects of flow-based Network Security 287 Functions. Examples of I2NSF Actions include providing intrusion 288 detection and/or protection, web and flow filtering, and deep 289 packet inspection for packets and flows. An I2NSF Action, when 290 used in the context of a I2NSF Policy Rule, may be executed when 291 both the Event and the Condition clauses of its owning I2NSF 292 Policy Rule evaluate to true. The execution of this Action may be 293 influenced by applicable metadata. (from 294 [I-D.ietf-supa-generic-policy-info-model]). 296 I2NSF Agent: A software Component in a device that implements an 297 NSF. It receives provisioning information and requests for 298 operational data (e.g., monitoring data) from an I2NSF Consumer. 299 It is also responsible for enforcing the policies that it 300 receives from an I2NSF Consumer. 302 I2NSF Capability: A set of features that are available from an NSF 303 Server or an NSF Controller. While both are Capabilities, the 304 former defines functions that are available from an NSF, whereas 305 the latter defines functions that are available from a security 306 Controller or other Management Entity. This definition is based 307 on that in [I-D.ietf-sacm-terminology]. 309 I2NSF Client: See I2NSF Consumer. 311 I2NSF Component: A Component that provides one or more I2NSF 312 Services. I2NSF Components are managed and communicate with other 313 I2NSF Components using I2NSF Interfaces. 315 I2NSF Consumer: A software Component that uses the I2NSF framework 316 to read, write, and/or change provisioning and operational aspects 317 of the NSFs that it attaches to. 319 I2NSF Consumer Interface: An Interface dedicated to requesting and 320 using I2NSF Services. For example, this Interface could be used 321 to request a set of Flow Security policies from an I2NSF 322 Controller or from one or more individual NSFs. The difference is 323 that the former uses more abstract Condition matching (e.g., 324 based on tenant or customer ID), whereas the latter uses more 325 low-level Condition matching (e.g., based on flow state or fields 326 in a flow or packet). See also: Interface, I2NSF Provider 327 Interface, Client-Facing Interface, NSF-Facing Interface. 329 I2NSF Management System: I2NSF Consumers operate within the scope of 330 a network management system, which serves as a collection and 331 distribution point for I2NSF security provisioning. 333 I2NSF Policy: A set of Policy Rules that are used to manage and 334 control the changing or maintaining of the state of an instance 335 of an NSF. 337 I2NSF Policy Rule: A Policy Rule that is adapted for I2NSF usage. 338 The I2NSF Policy Rule is assumed to be in ECA form (i.e., an 339 imperative structure). Other types of programming paradigms 340 (e.g., declarative and functional) are currently out of scope. 341 An example of an I2NSF Policy Rule is, in pseudo-code: 343 IF is TRUE 344 IF is TRUE 345 THEN execute 346 END-IF 347 END-IF 349 In the above example, the Event, Condition, and Action portions 350 of a Policy Rule are all **Boolean Clauses**. 352 I2NSF Provider Interface: An Interface dedicated to providing I2NSF 353 Services. For example, this could provide Anti-Virus, (D)DoS, or 354 IPS Services. See also: Interface, I2NSF Provider Interface, 355 Client-Facing Interface, NSF-Facing Interface. 357 I2NSF Registry: A registry that contains I2NSF capability 358 information, which can be controlled by the I2NSF Management 359 System. See also: Registry. 361 I2NSF Service: A set of functions, provided by an I2NSF Consumer, 362 which are used by zero or more I2NSF Producers. Exemplary I2NSF 363 Services include Anti-Virus, Authentication, Authorization, 364 (D)DoS, Firewall, and IPS Services. See also: Interface, I2NSF 365 Provider Interface, Client-Facing Interface, NSF-Facing Interface. 367 IDS: Intrusion Detection System (see below). 369 IPS: Intrusion Protection System (see below). 371 Information Model: A representation of concepts of interest to an 372 environment in a form that is independent of data repository, 373 data definition language, query language, implementation language, 374 and protocol [I-D.ietf-supa-generic-policy-info-model]. 376 Interface: A set of operations one object knows it can invoke on, 377 and expose to, another object. It is a subset of all operations 378 that a given object implements. The same object may have multiple 379 types of interfaces to serve different purposes. An example of 380 multiple interfaces can be seen by considering the interfaces 381 include a firewall uses; these include: 383 * multiple interfaces for data packets to traverse through, 384 * an interface for a controller to impose policy,or retrieve 385 the results of execution of a policy rule. 387 See also: Consumer Interface, I2NSF Interface, Provider Interface 389 Intrusion Detection System (IDS): A system that detects network 390 intrusions via a variety of filters, monitors, and/or probes. An 391 IDS may be stateful or stateless. 393 Intrusion Protection System (IPS): A system that protects against 394 network intrusions. An IPS may be stateful or stateless. 396 Management Plane: In the context of I2NSF, the Management Plane is 397 an architectural Component that provides common functions to 398 define the behavior of I2NSF Components. The primary use of the 399 Management Plane is to transport behavioral commands, and supply 400 OAM data, for making decisions that affect behavior. Examples 401 include modifying the configuration of an I2NSF Component and 402 transporting OAM data. See also: Control Plane, Data Plane. 404 Metadata: Data that provides information about other data. 405 Examples include IETF network management protocols (e.g. NETCONF, 406 RESTCONF, IPFIX) or IETF routing interfaces (I2RS). The I2NSF 407 security interface may utilize Metadata to describe and/or 408 prescribe characteristics and behavior of the YANG data models. 410 Middlebox: Any intermediary device performing functions other 411 than the normal, standard functions of an IP router on the 412 datagram path between a source host and destination host 413 [RFC3234]. 415 Network Security Function (NSF): Software that provides a set of 416 security-related services. Examples include detecting unwanted 417 activity and blocking or mitigating the effect of such unwanted 418 activity in order to fulfil service requirements. The NSF can 419 also help in supporting communication stream integrity and 420 confidentiality. 422 NSF-Facing Interface: An Interface dedicated to communication with 423 a set of NSFs. This is typically defined per I2NSF administrative 424 domain. See also: Interface, Consumer-Facing Interface. 426 OAM: Operation, Administrative, and Management. 428 OCL (Object Constraint Language): A constraint programming language 429 that is used to specify constraints (e.g., in UML) (from 430 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) 432 Policy Rule: A set of rules that are used to manage and control 433 the changing or maintaining of the state of one or more managed 434 objects. Often this is shortened to Rule or Policy (see I2NSF 435 policy rule). (from [I-D.ietf-supa-generic-policy-info-model]). 437 Profile: A structured representation of information that uses a 438 pre-defined set of capabilities of an object, typically in a 439 specific context. Zero or more Capabilities may be changed at 440 runtime. This may be used to simplify how this object interacts 441 with other objects in its environment. 443 Producer: A Producer is a Role that is assigned to an I2NSF 444 Component that can send information and/or commands to another 445 I2NSF Component. See also: Consumer, Role. 447 Registry: A logically centralized location containing data of a 448 particular type; it may optionally contain metadata, 449 relationships, and other aspects of the registered data in order 450 to use those data effectively. An I2NSF registry is used to 451 contain capability information that can be controlled by the 452 controller. 454 Registration Interface: An interface dedicated to requesting, 455 receiving, editing, and deleting information in a Registry. 457 Role: An abstraction of a Component that models context-specific 458 views and responsibilities of an object as separate Role objects. 459 Role objects can optionally be attached to, and removed from, the 460 object that the Role object describes at runtime. This provides 461 three important benefits. First, it enables different behavior 462 to be supported by the same Component for different contexts. 463 Second, it enables the behavior of a Component to be adjusted 464 dynamically (i.e., at runtime, in response to changes in context) 465 by using one or more Roles to define the behavior desired for 466 each context. Third, it decouples the Roles of a Component from 467 the Applications use that Component. 469 Service Interface: An Interface dedicated to enabling Policy Rules 470 to be managed. This is also called the I2NSF Consumer Interface. 472 Service Provider Security Controller: TBD (Editorial: Place holder 473 for a split between controller and security controller 474 definitions.) 476 Tenant: A group of users that share common access privileges to 477 the same software. An I2NSF tenant may be physical or virtual, 478 and may run on a variety of systems or servers. 480 Vendor-Facing Interface: An Interface dedicated to registering and 481 vendor-specific NSFs and Capabilities. It is also used to invoke 482 vendor-specific functionality. This is also called the NSF-Facing 483 Interface. 485 3. IANA Considerations 487 No IANA considerations exist for this document. 489 4. Security Considerations 491 This is a terminology document with no security considerations. 493 5. Contributors 495 The following people contributed to creating this document, and are 496 listed in alphabetical order: 498 Henk Birkholz 500 6. References 502 6.1. Informative References 504 [I-D.ietf-i2nsf-gap-analysis] 505 Hares, S., Moskowitz, R., and D. Zhang, "Analysis of 506 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-01 507 (work in progress), April 2016. 509 [I-D.ietf-i2nsf-problem-and-use-cases] 510 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 511 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 512 ietf-i2nsf-problem-and-use-cases-01 (work in progress), 513 July 2016. 515 [I-D.ietf-netmod-acl-model] 516 Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., 517 "Network Access Control List (ACL) YANG Data Model", 518 draft-ietf-netmod-acl-model-08 (work in progress), 519 July 2016. 521 [I-D.ietf-opsawg-firewalls] 522 Baker, F. and P. Hoffman, "On Firewalls in Internet 523 Security", draft-ietf-opsawg-firewalls-01 (work in 524 progress), October 2012. 526 [I-D.ietf-sacm-terminology] 527 Birkholz, H., Lu, J., Cam-Wignet, N., "Secure Automation 528 and Continuous Monitoring (SACM) Terminology", 529 draft-ietf-sacm-terminology-09, March 2016 531 [I-D.ietf-supa-generic-policy-info-model] 532 Strassner, J., Halpern, J., and J. Coleman, "Generic 533 Policy Information Model for Simplified Use of Policy 534 Abstractions (SUPA)", draft-ietf-supa-generic-policy- 535 info-model-00 (work in progress), June 2016. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 541 Accounting Management", RFC 2975, DOI 10.17487/RFC2975, 542 October 2000, . 544 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 545 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 546 . 548 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 549 Accounting (AAA) Transport Profile", RFC 3539, 550 DOI 10.17487/RFC3539, June 2003, 551 . 553 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 554 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 555 . 557 [X.1252] ITU-T, "Baseline identity management terms and 558 definitions", Recommendation ITU-T X.1252, April 2010 560 Authors' Addresses 562 Susan Hares 563 Huawei 564 7453 Hickory Hill 565 Saline, MI 48176 566 USA 567 Phone: +1-734-604-0332 568 Email: shares@ndzh.com 570 John Strassner 571 Huawei Technologies 572 Santa Clara, CA 573 USA 574 Email: john.sc.strassner@huawei.com 576 Diego R. Lopez 577 Telefonica I+D 578 Don Ramon de la Cruz, 82 579 Madrid 28006 580 Spain 581 Email: diego.r.lopez@telefonica.com 583 Liang Xia (Frank) 584 Huawei 585 101 Software Avenue, Yuhuatai District 586 Nanjing , Jiangsu 210012 587 China 588 Email: Frank.Xialiang@huawei.com