idnits 2.17.1 draft-ma-netmod-immutable-flag-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 (14 April 2022) is 733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-ma-netmod-with-system-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Q. Ma 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: 16 October 2022 B. Lengyel 6 Ericsson 7 H. Li 8 HPE 9 14 April 2022 11 YANG Extension and Metadata Annotation for Immutable Flag 12 draft-ma-netmod-immutable-flag-01 14 Abstract 16 This document defines a YANG extension named "immutable" to indicate 17 that specific data nodes are not allowed to be created/deleted/ 18 updated. To indicate that specific instances of a list/leaf-list 19 node cannot be changed after initialization, a metadata annotation 20 with the same name is also defined. Any data node or instance marked 21 as immutable is read-only to the clients of YANG-driven management 22 protocols, such as NETCONF, RESTCONF and other management operations 23 (e.g., SNMP and CLI requests). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 16 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. "Immutable" YANG Extension . . . . . . . . . . . . . . . . . 5 62 4. "Immutable" Metadata Annotation . . . . . . . . . . . . . . . 5 63 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 9 66 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 11 72 A.1. Interface Example . . . . . . . . . . . . . . . . . . . . 11 73 A.1.1. Creating an Interface with a "type" Value . . . . . . 12 74 A.1.2. Updating the Value of an Interface Type . . . . . . . 13 75 A.2. Immutable System Capabilities Modelled as "config 76 true" . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 A.3. Immutable System-defined List Entries . . . . . . . . . . 15 78 Appendix B. Changes between revisions . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 YANG [RFC7950] is a data modeling language used to model both state 84 and configuration data, based on the "config" statement. However 85 there exists data that should not be modifiable by the client, but 86 still needs to be declared as "config true" to: 88 * allow configuration of data nodes under immutable lists or 89 containers; 91 * ensure the existence of specific list entries that are provided 92 and needed by the system, while additional list entries can be 93 created, modified or deleted; 95 * place "when", "must" and "leafref" constraints between 96 configuration and immutable schema nodes. 98 E.g., the interface name and type values created by the system due to 99 the hardware currently present in the device cannot be modified by 100 clients, while configurations such as MTU created by the system are 101 free to be modified by the client. Further examples and use-cases 102 are described in Appendix A. 104 Allowing some configuration to be modifiable while other parts are 105 not is inconsistent and introduces ambiguity to clients. 107 To address this issue, this document defines a YANG extension and a 108 metadata annotation [RFC7952] named "immutable" to indicate the 109 immutability characteristic of a particular schema node or 110 instantiated data node. If a schema node is marked as immutable, 111 data nodes based on the schema MUST NOT be added, removed or updated 112 by management protocols, such as NETCONF, RESTCONF or other 113 management operations (e.g., SNMP and CLI requests). If an 114 instantiated data node is marked as immutable the server MUST reject 115 changes to it by YANG-driven management protocols, such as NETCONF, 116 RESTCONF and other management operations (e.g., SNMP and CLI 117 requests). Marking instance data nodes as immutable (as opposed to 118 marking schema-nodes) is important when only some instances of a list 119 or leaf-list shall be marked as read-only. 121 Theoretically, any "config true" data node is allowed to be created, 122 updated and deleted. This work makes write access restrictions other 123 than general YANG and NACM rules visible, which doesn't mean 124 attaching such restrictions is encouraged. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 The following terms are defined in [RFC6241] and [RFC8341] and are 135 not redefined here: 137 * configuration data 139 * access operation 141 * write access 142 The following terms are defined in this document: 144 immutable: A property indicating that a schema node is not allowed 145 to be created/deleted/updated. When annotating an instance of a 146 list/leaf-list, it indicates that the instance cannot be updated 147 once it's created. The immutability of a specific data node or 148 instance is datastore-independent, protocol-independent and user- 149 independent. 151 2. Overview 153 The "immutable" concept only puts write access restrictions to read- 154 write datastores. When a specific data node or instance is marked as 155 "immutable", NACM cannot override this to allow create/delete/update 156 access. 158 Immutability is a property of the object itself. A particular data 159 node or instance MUST have the same immutability in all read-write 160 datastores. The immutable property should be visible even in read- 161 only datastores (e.g., , , ), however 162 this only serves as information about the data node itself, but has 163 no effect on the handling of the read-only datastore. In addition, 164 the immutability property of a particular data node or instance MUST 165 NOT change due to different network management protocols and users. 167 If a particular list/leaf-list node is marked as "immutable" without 168 exceptions for "update" in the schema (e.g., a list data node is 169 always immutable and an update is not allowed), the server SHOULD NOT 170 annotate its instances duplicately. 172 Servers MUST reject any attempt to the "create", "delete" and 173 "update" access operations on an immutable data node or instance; 174 marked by YANG extension (except according to the exceptions 175 argument) or metadata annotation. The error reporting is performed 176 at various different time according to the selected read-write target 177 datastore. If the target datastore is "running", the server should 178 reply with an "invalid-value" at a operation time. If 179 the target datastore is "candidate", the "invalid-value" error 180 response to update an immutable data node is delayed until a 181 or operation takes place. For an example of an "invalid- 182 value" error response, see Appendix A.1.2. 184 However the following operations SHOULD be allowed: 186 * Use a create, update, delete/remove operation on an immutable 187 node/instance if the effective change is null. E.g. If a leaf 188 has a current value of "5" it should be allowed to replace it with 189 a value of "5". 191 * Create an immutable data node/instance with a same value initially 192 set by the system if it doesn't exist in the datastore, e.g., 193 explicitly configure a system generated interface name and type in 194 ; 196 3. "Immutable" YANG Extension 198 The "immutable" YANG extension can be a substatement to a leaf, leaf- 199 list, container, list, anydata or anyxml statement. It indicates 200 that data nodes based on the parent statement MUST NOT be added, 201 removed or updated except according to the exceptions argument. The 202 server MUST reject any such write attempt. 204 The "immutable" YANG extension defines an argument statement named 205 "exceptions" which gives a list of operations that users are 206 permitted to invoke for the specified node. 208 The following values are supported for the "exceptions" argument: 210 * Create: allow users to create instances of the data node; 212 * Update: allow users to modify instances of the data node; 214 * Delete: allow users to delete instances of the data node. 216 4. "Immutable" Metadata Annotation 218 The "immutable" flag is used to indicate the immutability of a 219 particular instantiated data node. It only applies to the list/leaf- 220 list entries. The values are boolean types indicating whether the 221 data node instance is immutable or not. 223 Any list/leaf-list instance annotated with immutable="true" is read- 224 only to clients, which means that once an instance is created, the 225 client cannot change it. If a list entry is annotated with 226 immutable="true", any contained descendant instances of any type 227 (including leafs, lists, containers, etc.) inside the specific 228 instance is not allowed to be created, updated and deleted without 229 the need to annotate descendant nodes instances explicitly. 231 Note that "immutable" metadata annotation is used to annotate 232 instances of a list/leaf-list rather than schema nodes. For 233 instance, a list node may exist in multiple instances in the data 234 tree, "immutable" can annotate some of the instances as read-only, 235 while others are not. 237 When the client retrieves a particular datastore, immutable data node 238 instances MUST be annotated with immutable="true" by the server. If 239 the "immutable" metadata annotation inside a list entry is not 240 specified, the default "immutable" value for a list/leaf-list entry 241 is false. 243 Different from the "immutable" YANG extension, deletion to an 244 instance marked with immutable="true" metadata annotation SHOULD 245 always be allowed unless the list/leaf-list data node in the schema 246 has an im:immutable extension as substatement without a "delete" 247 exception. 249 5. YANG Module 251 252 file="ietf-immutable@2022-03-28.yang" 253 module ietf-immutable { 254 yang-version 1.1; 255 namespace "urn:ietf:params:xml:ns:yang:ietf-immutable"; 256 prefix im; 258 import ietf-yang-metadata { 259 prefix md; 260 } 262 organization 263 "IETF Network Modeling (NETMOD) Working Group"; 265 contact 266 "WG Web: 268 WG List: 270 Author: Qiufang Ma 271 273 Author: Qin Wu 274 276 Author: Balazs Lengyel 277 279 Author: Hongwei Li 280 "; 282 description 283 "This module defines a metadata annotation named 'immutable' 284 to indicate the immutability of a particular instantiated 285 data node. Any instantiated data node marked with 286 immutable='true' by the server is read-only to the clients 287 of YANG-driven management protocols, such as NETCONF, 288 RESTCONF as well as SNMP and CLI requests. 290 The module defines the immutable extension that indicates 291 that data nodes based ona data-dafinition statement cannot 292 be added removed or updated except according to the 293 exceptions argument. 295 Copyright (c) 2022 IETF Trust and the persons identified 296 as authors of the code. All rights reserved. 298 Redistribution and use in source and binary forms, with 299 or without modification, is permitted pursuant to, and 300 subject to the license terms contained in, the Simplified 301 BSD License set forth in Section 4.c of the IETF Trust's 302 Legal Provisions Relating to IETF Documents 303 (https://trustee.ietf.org/license-info). 305 This version of this YANG module is part of RFC HHHH 306 (https://www.rfc-editor.org/info/rfcHHHH); see the RFC 307 itself for full legal notices. 309 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 310 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 311 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 312 are to be interpreted as described in BCP 14 (RFC 2119) 313 (RFC 8174) when, and only when, they appear in all 314 capitals, as shown here."; 316 revision 2022-03-28 { 317 description 318 "Initial revision."; 319 reference 320 "RFC XXX: Immutable Metadata Annotation"; 321 } 323 extension immutable { 324 argument exceptions; 325 description 326 "The 'immutable' extension as a substatement to a data 327 definition statement indicates that data nodes based on 328 the parent statement MUST NOT be added, removed or 329 updated by management protocols, such as NETCONF, 330 RESTCONF or other management operations (e.g., SNMP 331 and CLI requests) except when indicated by the 332 exceptions argument. 334 Immutable data MAY be marked as config true to allow 335 'leafref', 'when' or 'must' constraints to be based 336 on it. 338 The statement MUST only be a substatement of the leaf, 339 leaf-list, container, list, anydata, anyxml statements. 340 Zero or one immutable statement per parent statement 341 is allowed. 342 NO substatements are allowed. 344 The argument is a list of operations that users are 345 permitted to be used for the specified node, while 346 other operations are forbidden by the immutable extension. 347 - create: allows users to create instances of the object 348 - update : allows users to modify instances of the object 349 - delete : allows users to delete instances of the object 351 To dis-allow all user write access, omit the argument; 353 To allow only create and delete user access, provide 354 the string 'create delete' for the 'exceptions' parameter. 356 Providing all 3 parameters has the same affect as not 357 using this extension at all, but can be used anyway. 359 Equivalent YANG definition for this extension: 361 leaf immutable { 362 type bits { 363 bit create; 364 bit update; 365 bit delete; 366 } 367 default ''; 368 } 370 Adding immutable or removing values from the 371 exceptions argument of an existing immutable statement 372 are non-backwards compatible changes. 373 Other changes to immutable are backwards compatible."; 374 } 375 md:annotation immutable { 376 type boolean; 377 description 378 "The 'immutable' annotation indicates the immutability of an 379 instantiated data node. Any data node instance marked as 380 'immutable=true' is read-only to clients and cannot be 381 updated through NETCONF, RESTCONF or CLI. It applies to the 382 list and leaf-list entries. The default is 'immutable=false' 383 if not specified for an instance."; 384 } 385 } 386 388 6. IANA Considerations 390 6.1. The "IETF XML" Registry 392 This document registers one XML namespace URN in the 'IETF XML 393 registry', following the format defined in [RFC3688]. 395 URI: urn:ietf:params:xml:ns:yang:ietf-immutable 396 Registrant Contact: The IESG. 397 XML: N/A, the requested URIs are XML namespaces. 399 6.2. The "YANG Module Names" Registry 401 This document registers one module name in the 'YANG Module Names' 402 registry, defined in [RFC6020]. 404 name: ietf-immutable 405 prefix: im 406 namespace: urn:ietf:params:xml:ns:yang:ietf-immutable 407 RFC: XXXX // RFC Ed.: replace XXXX and remove this comment 409 7. Security Considerations 411 The YANG module specified in this document defines a metadata 412 annotation for data nodes that is designed to be accessed network 413 management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 414 The lowest NETCONF layer is the secure transport layer, and the 415 mandatory-to-implement secure transport is Secure Shell (SSH) 416 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 417 implement secure transport is TLS [RFC8446]. 419 Since immutable information is tied to applied configuration values, 420 it is only accessible to clients that have the permissions to read 421 the applied configuration values. 423 The security considerations for the Defining and Using Metadata with 424 YANG (see Section 9 of [RFC7952]) apply to the metadata annotation 425 defined in this document. 427 8. References 429 8.1. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 437 DOI 10.17487/RFC3688, January 2004, 438 . 440 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 441 the Network Configuration Protocol (NETCONF)", RFC 6020, 442 DOI 10.17487/RFC6020, October 2010, 443 . 445 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 446 and A. Bierman, Ed., "Network Configuration Protocol 447 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 448 . 450 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 451 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 452 . 454 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 455 RFC 7950, DOI 10.17487/RFC7950, August 2016, 456 . 458 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 459 RFC 7952, DOI 10.17487/RFC7952, August 2016, 460 . 462 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 463 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 464 . 466 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 467 Access Control Model", STD 91, RFC 8341, 468 DOI 10.17487/RFC8341, March 2018, 469 . 471 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 472 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 473 . 475 8.2. Informative References 477 [I-D.ma-netmod-with-system] 478 Ma, Q., Watsen, K., Wu, Q., Chong, F., and J. Lindblad, 479 "System-defined Configuration", Work in Progress, 480 Internet-Draft, draft-ma-netmod-with-system-03, 10 April 481 2022, . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 485 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 486 May 2017, . 488 Appendix A. Usage Examples 490 A.1. Interface Example 492 This section shows how to use im:immutable YANG extension to mark 493 some data node as immutable. 495 When an interface is physically present, the system will create an 496 interface entry automatically with valid name and type values in 497 (see [I-D.ma-netmod-with-system]). The system-generated 498 data is dependent on and must represent the HW present, and as a 499 consequence must not be changed by the client. The data is modelled 500 as "config true" and should be marked as immuable. 502 Seemingly an alternative would be to model the list and these leaves 503 as "config false", but that does not work because: 505 * The list cannot be marked as "config false", because it needs to 506 contain configurable child nodes, e.g., ip-address or enabled; 508 * The key leaf (name) cannot be marked as "config false" as the list 509 itself is config true; 511 * The type cannot be marked "config false", because we MAY need to 512 reference the type to make different configuration nodes 513 conditionally available. 515 The immutability of the data is the same for all interface instances, 516 thus following fragment of a fictional interface module including an 517 "immutable" YANG extension can be used: 519 container interfaces { 520 list interface { 521 key "name"; 522 leaf name { 523 type string; 524 } 525 leaf type { 526 im:immutable "create"; 527 type identityref { 528 base ianaift:iana-interface-type; 529 } 530 mandatory true; 531 } 532 leaf mtu { 533 type uint16; 534 } 535 leaf-list ip-address { 536 type inet:ip-address; 537 } 538 } 539 } 541 Note that the "name" leaf is defined as a list key which can never 542 been modified for a particular list entry, there is no need to mark 543 "name" as immutable. 545 A.1.1. Creating an Interface with a "type" Value 547 As defined in the YANG model, there is an exception for "create" 548 operation. Assume the interface hardware is not present physically 549 at this point, the client is allowed to create an interface named 550 "eth0" with a type value in : 552 554 555 556 557 558 559 562 eth0 563 ianaift:ethernetCsmacd 564 565 566 567 569 571 572 574 The interface data does not appear in since the 575 physical interface doesn't exist. When the interface is inserted, 576 the system will detect it and create the associated configuration in 577 . The system tries to merge the interface configuration in 578 the datastore with the same name as the inserted interface 579 configuration in . If no such interface configuration named 580 "eth0" is found in or the type set by the client doesn't 581 match the real interface type generated by the system, only the 582 system-defined interface configuration is applied and present in 583 . 585 A.1.2. Updating the Value of an Interface Type 587 Assume the system applied the interface configuration named "eth0" 588 successfully. If a client tries to change the type of an interface 589 to a value that doesn't match the real type of the interface used by 590 the system, the server must reject the request: 592 595 596 597 598 599 600 602 eth0 603 ianaift:tunnel 604 605 606 607 609 612 613 application 614 invalid-value 615 error 616 617 /interfaces/interface[name="eth0"]/type 618 619 620 Invalid type for interface eth0 621 622 623 625 A.2. Immutable System Capabilities Modelled as "config true" 627 System capabilities might be represented as system-set data nodes in 628 the model. Configurable data nodes might need constraints specified 629 as "when", "must" or "path" statements to ensure that configuration 630 is set according to the system's capabilities. E.g., 632 * A timer can support the values 1,5,8 seconds. This is defined in 633 the leaf-list 'supported-timer-values'. 635 * When the configurable 'interface-timer' leaf is set, it should be 636 ensured that one of the supported values is used. The natural 637 solution would be to make the 'interface-timer' a leaf-ref 638 pointing at the 'supported-timer-values'. 640 However, this is not possible as 'supported-timer-values' must be 641 readOnly thus config=false while 'interface-timer' must be writable 642 thus config=true. According to the rules of YANG it is not allowed 643 to put a constraint between config true and false schema nodes. 645 The solution is that the supported-timer-values data node in the YANG 646 Model shall be defined as "config true" and shall also be marked with 647 the "immutable" extension. After this the 'interface-timer' shall be 648 defined as a leaf-ref pointing at the 'supported-timer-values'. 650 A.3. Immutable System-defined List Entries 652 There are some system-defined entries for a "config true" list which 653 are present in (see [I-D.ma-netmod-with-system]) and cannot 654 be updated by the client, such system-defined instances should be 655 defined immutable. The client is free to define, update and delete 656 their own list entries in . Thus the list data node in the 657 YANG model cannot be marked as "immutable" extension as a whole. But 658 some of the system-defined list entries need to be protected if they 659 are copied from the datastore to . 661 An immutable metadata annotation can be useful in this case. When 662 the client retrieves those system-defined entries towards 663 (or if they are copied into ), an immutable="true" 664 annotation is returned; so that the client can understand that the 665 predefined list entries shall not be updated but they can configure 666 their list entries without any restriction. 668 Appendix B. Changes between revisions 670 Note to RFC Editor (To be removed by RFC Editor) 672 v00 - v01 674 * Added immutable extension 676 * Added new use-cases for immutable extension and annotation 678 * Added requirement that an update that means no effective change 679 should always be allowed 681 * Added clarification that immutable is only applied to read-write 682 datastore 684 * Narrowed the applied scope of metadata annotation to list/leaf- 685 list instances 687 Authors' Addresses 689 Qiufang Ma 690 Huawei 691 101 Software Avenue, Yuhua District 692 Nanjing 693 Jiangsu, 210012 694 China 695 Email: maqiufang1@huawei.com 697 Qin Wu 698 Huawei 699 101 Software Avenue, Yuhua District 700 Nanjing 701 Jiangsu, 210012 702 China 703 Email: bill.wu@huawei.com 705 Balazs Lengyel 706 Ericsson 707 Email: balazs.lengyel@ericsson.com 709 Hongwei Li 710 HPE 711 Email: flycoolman@gmail.com