idnits 2.17.1 draft-wu-netmod-base-notification-nmda-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([RFC8342]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 246 has weird spacing: '...eration enu...' -- The document date (February 25, 2019) is 1881 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) == Missing Reference: 'RFC8040' is mentioned on line 75, but not defined == Missing Reference: 'RFC8174' is mentioned on line 108, but not defined == Missing Reference: 'RFC8340' is mentioned on line 222, but not defined == Missing Reference: 'RFC7950' is mentioned on line 663, but not defined == Unused Reference: 'RFC6020' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'RFC8072' is defined on line 721, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netmod-nmda-diff-00 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group Q. Wu 3 Internet-Draft C. Feng 4 Intended status: Standards Track R. Ranade 5 Expires: August 29, 2019 Huawei 6 February 25, 2019 8 NMDA Base Notification for Applied Intended Configuration 9 draft-wu-netmod-base-notification-nmda-01 11 Abstract 13 The Network Configuration Protocol (NETCONF)and RESTCONF provides 14 mechanisms to manipulate configuration datastores. NMDA introduces 15 additional datastores for systems that support more advanced 16 processing chains converting configuration to operational state. 17 However, client applications are not able to be aware of common 18 events in these additional datstores of the management system, such 19 as a applied configuration state change in NETCONF server or RESTCONF 20 server, that may impact management applications. This document 21 define a YANG module that allows a client to receive additional 22 notifications for some common system events pertaining to the Network 23 Management Datastore Architecture (NMDA) defined in [RFC8342]. 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 August 29, 2019. 42 Copyright Notice 44 Copyright (c) 2019 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. NMDA Base Notifications for applied intended configuration . 3 62 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Data Model Design . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Relation with NMDA Datastore Compare . . . . . . . . . . 7 65 2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 72 1. Introduction 74 The Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 75 [RFC8040] provides mechanisms to manipulate configuration datastores. 76 NMDA introduces additional datastores (e.g., , 77 ) for systems that support more advanced processing 78 chains converting configuration to operational state. However, 79 client applications are not able to be aware of common events in 80 those additional datastores of the management system, e.g., there are 81 many background activities (e.g.,NMDA datastore consistency checking 82 [I-D.ietf-netmod-nmda-diff]) that happen during the time that 83 configuration is committed to to the time that the 84 configuration is actually applied to . It is possible 85 that some configuration could not be applied to due to 86 either validation issues, or missing resource, etc. There is a need 87 for user to know the applying result of datastore and the 88 reason why the configuration were not applied. 90 This document define a YANG module that allows a NMS client to 91 receive additional notifications for some common system events 92 pertaining to the Network Management Datastore Architecture (NMDA) 93 defined in [RFC8342]. These notifications are designed to support 94 the monitoring of the base system events within the server and not 95 specific to any network management protocols such as NETCONF and 96 RESTCONF. 98 The solution presented in this document is backwards compatible with 99 [RFC6470]. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 The following terms are defined in [RFC8342] and are not redefined 110 here: 112 o operational state datastore 114 o running configuration datastore 116 o intended configuration datastore 118 2. NMDA Base Notifications for applied intended configuration 120 2.1. Overview 122 The YANG module in NETCONF Base Notifications [RFC6470] specifies the 123 following 5 event notifications for the 'NETCONF' stream to notify a 124 client application that the NETCONF server state has changed: 126 o netconf-config-change 128 o netconf-capability-change 130 o netconf-session-start 132 o netconf-session-end 134 o netconf-confirmed-commit 136 These event notifications used within the 'NETCONF' stream are 137 accessible to clients via the subscription mechanism described in 138 [RFC5277]. 140 This document introduces NMDA specific extension which allows a 141 client to receive 2 notifications for additional common system events 142 as follows: 144 apply-intended-start: Generated when a server with network 145 management protocol support detects that configuration applied 146 from intended has started. A server MAY optionally generate this 147 event for both NETCONF session and non-NETCONF management 148 sessions. Note that configuration applying process of the learned 149 configuration, system-provided configuration, and default values 150 defined by data models is not relevant to the events defined in 151 this document. The apply-intended-start starts at the time when 152 configuration is successfully committed to , i.e., the 153 confirmed-commit procedure has been completed. In case two 154 commits are detected, if the second commit is confirmed commit, 155 the confirming commit and confirmed commit should be treated as 156 the same commit, i.e., intended-apply-start should not be sent 157 again for persistent confirmed commit. If the second commit is 158 not confirmed commit, intended-apply-start for the second commit 159 should not be sent until nmda-intended-applied for the first 160 commit has been sent. 162 apply-intended-updated: Generated when a server with network 163 management protocol support detects that all or a set of 164 configurations are successfully applied or none of them are 165 applied. Indicates the event and the current state of the 166 intended configuration applying. In addition, NMDA datastore 167 compare [I-D.ietf-netmod-nmda-diff] should be used to check which 168 part of intended configuration data is applied or which part of 169 intended configuration data is not applied. A server MAY report 170 events for non- NETCONF management sessions (such as 171 RESTCONF,gPRC), using the 'session-id' value of zero. 173 The following figure shows event notification sequence defined in 174 this document. 176 +-------------+ +-----------+ 177 | | | | 178 | (ct, rw) |<---+ +--->| (ct, rw) | 179 +-------------+ | | +-----------+ 180 | | | | 181 | +-----------+ | 182 +-------->| |<--------+ 183 | (ct, rw) | 184 +-----------+ 185 | 186 (a)apply-intended-start | // configuration transformations, 187 | // e.g., removal of nodes marked as 188 | // "inactive", expansion of 189 | // templates 190 v 191 +------------+ 192 | | // subject to validation 193 | (ct, ro) | 194 +------------+ 195 | // changes applied, subject to 196 (b)apply-intended-updated | // local factors,e.g., missing 197 | // resources, delays 198 | 199 dynamic | +-------- learned configuration 200 configuration | +-------- system configuration 201 datastores -----+ | +-------- default configuration 202 | | | 203 v v v 204 +---------------+ 205 | | <-- system state 206 | (ct + cf, ro) | 207 +---------------+ 209 ct = config true; cf = config false 210 rw = read-write; ro = read-only 211 boxes denote named datastores 213 These notification messages are accessible to clients via either the 214 subscription mechanism described in [RFC5277] or dynamic subscription 215 mechanism and configured subscription mechanism described in [I- 216 D.ietf-netconf-netconf-event-notifications]. 218 2.2. Data Model Design 220 The data model is defined in the ietf-nmda-notifications YANG module. 221 Its structure is shown in the following figure. The notation syntax 222 follows [RFC8340]. 224 notifications: 225 +---n apply-intended-start {apply-start}? 226 | +--ro username string 227 | +--ro session-id session-id-or-zero-type 228 | +--ro app-tag? tags:tag 229 | +--ro source-host? inet:ip-address 230 | +--ro commit-persist-id? string 231 +---n apply-intended-updated 232 +--ro username string 233 +--ro session-id session-id-or-zero-type 234 +--ro app-tag? tags:tag 235 +--ro source-host? inet:ip-address 236 +--ro commit-persist-id? string 237 +--ro datastore? identityref 238 +--ro (filter-spec)? 239 | +--:(subtree-filter) 240 | | +--ro subtree-filter? 241 | +--:(xpath-filter) 242 | +--ro xpath-filter? yang:xpath1.0 {nc:xpath}? 243 +--ro apply-result? enumeration 244 +--ro fail-applied-target* [edit-id] 245 +--ro edit-id string 246 +--ro operation enumeration 247 +--ro target? ypatch:target-resource-offset 248 +--ro value? 249 +--ro errors 250 +--ro error* [] 251 +--ro error-type enumeration 252 +--ro error-tag string 253 +--ro error-app-tag? string 254 +--ro error-path? instance-identifier 255 +--ro error-message? string 256 +--ro error-info? 258 The following are examples of a apply-intended-updated notification 259 message: 261 262 2017-06-16T16:30:59.137045+09:00 263 264 admin 265 0 266 user:app1 267 10.251.93.83 268 IQ,d4668 269 fail 270 operational 271 272 1 273 merge 274 /ietf-interfaces:interfaces-state 275 276 277 278 eth0 279 down 280 281 282 283 284 285 2 286 /ietf-system:system 287 288 protocol 289 mis-resource 290 \ 291 \/if:interfaces-state\ 292 \ 293 refer to resources that are not \ 294 \available or otherwise not physically present.\ 295 \ 296 297 298 299 301 2.3. Relation with NMDA Datastore Compare 303 NMDA datastore compare [NMDA-DIFF]could be used to check which part 304 of intended configuration data is applied or which part of intended 305 configuration data is not applied. On the other hand, the event 306 notification for apply-intended-start or netconf-confirmed-commit can 307 be used to trigger NMDA datastore compare procedure to be started. 309 2.4. Definitions 311 This section presents the YANG module defined in this document. This 312 module imports data types from the 'ietf-datastores' module defined 313 in [RFC8342] and 'ietf-inet-types' module defined in [RFC6021]. 315 file "ietf-nmda-notifications@2018-12-26.yang" 316 module ietf-nmda-notifications { 317 yang-version 1.1; 318 namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-notifications"; 319 prefix ndn; 320 import ietf-datastores { 321 prefix ds; 322 } 323 import ietf-inet-types { prefix inet; } 324 import ietf-module-tags { prefix tags;} 325 import ietf-yang-types { prefix yang;} 326 import ietf-yang-patch { 327 prefix ypatch; 328 } 329 import ietf-netconf { 330 prefix nc; 331 } 332 import ietf-restconf { prefix rc;} 333 organization 334 "IETF NETMOD (Network Modeling) Working Group"; 335 contact 336 "WG Web: 337 WG List: 338 WG Chair: Kent Watsen 339 340 Editor: Qin Wu 341 342 Editor: Rohit R Ranade 343 "; 344 description 345 "This module defines a YANG data model for use with the 346 NETCONF and RESTCONF protocol that allows the client to 347 receive additional common event notifications related to NMDA. 349 Copyright (c) 2012 IETF Trust and the persons identified as 350 the document authors. All rights reserved. 351 Redistribution and use in source and binary forms, with or 352 without modification, is permitted pursuant to, and subject 353 to the license terms contained in, the Simplified BSD License 354 set forth in Section 4.c of the IETF Trust's Legal Provisions 355 Relating to IETF Documents 356 (http://trustee.ietf.org/license-info). 357 This version of this YANG module is part of RFC xxxx; see 358 the RFC itself for full legal notices."; 360 revision 2018-12-26 { 361 description 362 "Initial version."; 363 reference "RFC xxx: NETCONF Base Notifications for NMDA"; 364 } 365 typedef session-id-or-zero-type { 366 type uint32; 367 description 368 "NETCONF Session Id or Zero to indicate none"; 369 } 370 feature error-info { 371 description 372 "This feature must 373 also be enabled for that session if error-info 374 can be advertised by the server. Otherwise, 375 this feature must not be enabled."; 376 } 377 feature apply-start { 378 description 379 " This feature must 380 also be enabled for that session if apply-intended-start 381 can be supported by the server. Otherwise, 382 this feature must not be enabled."; 383 } 385 grouping common-session-parms { 386 description 387 "Common session parameters to identify a 388 management session."; 390 leaf username { 391 type string; 392 mandatory true; 393 description 394 "Name of the user for the session."; 395 } 397 leaf session-id { 398 type session-id-or-zero-type; 399 mandatory true; 400 description 401 "Identifier of the session. 402 A NETCONF session MUST be identified by a non-zero value. 403 A non-NETCONF session MAY be identified by the value zero."; 404 } 405 leaf app-tag { 406 type tags:tag; 407 description 408 "The relationship between username and application tag 409 can be one to many."; 410 } 412 leaf source-host { 413 type inet:ip-address; 414 description 415 "Address of the remote host for the session."; 416 } 418 leaf commit-persist-id { 419 type string; 420 description 421 "This parameter is used to identify each commit. 422 The value of this parameter is a token that must be given 423 in the 'persist-id' parameter of or 424 operations in order to confirm or cancel 425 the persistent confirmed commit. 427 The token should be a random string."; 428 reference "RFC 6241, Section 8.3.4.1"; 429 } 430 } 432 notification apply-intended-start { 433 if-feature apply-start; 434 description 435 " Generated when a server detects that applied configuration 436 From intended has started. This event will be sent immediately 437 upon any data is written to . A server MAY generate 438 this event for both NETCONF session and non-NETCONF management 439 sessions."; 440 uses common-session-parms; 441 } // notification applied-intended-start 443 notification apply-intended-updated { 444 description 445 "Generated when a server detects that a 446 intended configuration applied event has occurred. Indicates 447 the event and the current state of the intended data applying 448 procedure in progress."; 449 reference "RFC 8342, Section 5"; 450 uses common-session-parms; 451 leaf datastore { 452 type identityref { 453 base ds:datastore; 454 } 455 default "ds:operational"; 456 description 457 "Indicates which datastore has changed or which datastore is 458 target of edit-data operation."; 459 } 460 choice filter-spec { 461 description 462 "The content filter specification for this request."; 463 anydata subtree-filter { 464 description 465 "This parameter identifies the portions of the 466 target datastore to retrieve."; 467 reference 468 "RFC 6241: Network Configuration Protocol, Section 6."; 469 } 470 leaf xpath-filter { 471 if-feature nc:xpath; 472 type yang:xpath1.0; 473 description 474 "This parameter contains an XPath expression identifying 475 the portions of the target datastore to retrieve. 477 If the expression returns a node-set, all nodes in the 478 node-set are selected by the filter. Otherwise, if the 479 expression does not return a node-set, then the get-data 480 operation fails. 482 The expression is evaluated in the following XPath 483 context: 485 o The set of namespace declarations are those in 486 scope on the 'xpath-filter' leaf element. 488 o The set of variable bindings is empty. 490 o The function library is the core function library, 491 and the XPath functions defined in section 10 in 492 RFC 7950. 494 o The context node is the root node of the target 495 datastore."; 496 } 497 } 498 leaf apply-result { 499 type enumeration { 500 enum "ok" { 501 description 502 "The intended data is succesfully applied."; 503 } 504 enum "fail" { 505 description 506 " The intended data is not succesfully applied."; 507 } 508 } 509 description 510 "Apply result."; 511 } 512 list fail-applied-target { 513 when "../apply-result = 'fail'"; 514 key edit-id; 515 ordered-by user; 516 leaf edit-id { 517 type string; 518 description 519 "Response status is for the 'edit' list entry 520 with this 'edit-id' value."; 521 } 522 leaf operation { 523 type enumeration { 524 enum create { 525 description 526 "The target data node is created using the supplied 527 value, only if it does not already exist. The 528 'target' leaf identifies the data node to be 529 created, not the parent data node."; 530 } 531 enum delete { 532 description 533 "Delete the target node, only if the data resource 534 currently exists; otherwise, return an error."; 535 } 537 enum insert { 538 description 539 "Insert the supplied value into a user-ordered 540 list or leaf-list entry. The target node must 541 represent a new data resource. If the 'where' 542 parameter is set to 'before' or 'after', then 543 the 'point' parameter identifies the insertion 544 point for the target node."; 545 } 546 enum merge { 547 description 548 "The supplied value is merged with the target data 549 node."; 550 } 551 enum move { 552 description 553 "Move the target node. Reorder a user-ordered 554 list or leaf-list. The target node must represent 555 an existing data resource. If the 'where' parameter 556 is set to 'before' or 'after', then the 'point' 557 parameter identifies the insertion point to move 558 the target node."; 559 } 560 enum replace { 561 description 562 "The supplied value is used to replace the target 563 data node."; 564 } 565 enum remove { 566 description 567 "Delete the target node if it currently exists."; 568 } 569 } 570 mandatory true; 571 description 572 "The datastore operation requested for the associated 573 'edit' entry."; 574 } 575 leaf target { 576 type ypatch:target-resource-offset; 577 description 578 "Topmost node associated with the configuration change. 579 A server SHOULD set this object to the node within 580 the datastore that is being altered. A server MAY 581 set this object to one of the ancestors of the actual 582 node that was changed, or omit this object, if the 583 exact node is not known."; 584 } 585 anydata value { 586 description 587 "Value used for this edit operation. The anydata 'value' 588 contains the target resource associated with the 589 'target' leaf. 591 For example, suppose the target node is a YANG container 592 named foo: 594 container foo { 595 leaf a { type string; } 596 leaf b { type int32; } 597 } 599 The 'value' node contains one instance of foo: 601 602 603 some value 604 42 605 606 607 "; 608 } 609 uses rc:errors {if-feature error-info;} 610 description 611 "List for fail applied targets. The fail applied targets 612 are only applied when the intended data is not applied."; 613 } 614 } 615 } 616 618 3. Security Considerations 620 The YANG module defined in this memo is designed to be accessed via 621 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 622 secure transport layer and the mandatory-to-implement secure 623 transport is SSH, defined in [RFC6242]. 625 Some of the readable data nodes in this YANG module may be considered 626 sensitive or vulnerable in some network environments. It is thus 627 important to control read access (e.g., via get, get-config, or 628 notification) to these data nodes. These are the subtrees and data 629 nodes and their sensitivity/vulnerability: 631 /apply-intended-start: 633 Event type itself indicates that a server may start applying 634 configuration from intended. It may be possible for an attacker 635 to slow down intended validation or update intended independently 636 of running by somehow taking advantage of configuration template 637 transformation. 639 /apply-intended-updated: 641 Event type itself indicates that a server may be finished applying 642 configuration from intended. This event could alert an attacker 643 that a datastore may have been altered. 645 /apply-intended-updated/apply-result: 647 Indicates the specific applied intended applied event state change 648 that occurred. A value of 'ok' probably indicates that intended 649 data applying procedure has completed. 651 4. IANA Considerations 653 This document registers one XML namespace URN in the 'IETF XML 654 registry', following the format defined in [RFC3688]: 656 URI: urn:ietf:params:xml:ns:yang:ietf-nmda-notifications 658 Registrant Contact: The IESG. 660 XML: N/A, the requested URI is an XML namespace. 662 This document registers one module name in the 'YANG Module Names' 663 registry, defined in [RFC7950]: 665 name: ietf-nmda-notifications 667 prefix: ndn 669 namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-notifications 671 RFC: xxxx 673 5. Acknowledgements 675 Thanks to Juergen Schoenwaelder, Alex Clemm,Carey Timothy and Andy 676 Berman to review this draft and Thank Xiaojian Ding provide important 677 input to the initial version of this document. 679 6. Normative References 681 [I-D.ietf-netmod-nmda-diff] 682 Clemm, A., Qu, Y., Tantsura, J., and A. Bierman, 683 "Comparison of NMDA datastores", draft-ietf-netmod-nmda- 684 diff-00 (work in progress), October 2018. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, 688 DOI 10.17487/RFC2119, March 1997, 689 . 691 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 692 DOI 10.17487/RFC3688, January 2004, 693 . 695 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 696 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 697 . 699 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 700 the Network Configuration Protocol (NETCONF)", RFC 6020, 701 DOI 10.17487/RFC6020, October 2010, 702 . 704 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 705 RFC 6021, DOI 10.17487/RFC6021, October 2010, 706 . 708 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 709 and A. Bierman, Ed., "Network Configuration Protocol 710 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 711 . 713 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 714 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 715 . 717 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 718 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 719 February 2012, . 721 [RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 722 Media Type", RFC 8072, DOI 10.17487/RFC8072, February 723 2017, . 725 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 726 and R. Wilton, "Network Management Datastore Architecture 727 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 728 . 730 Authors' Addresses 732 Qin Wu 733 Huawei 734 101 Software Avenue, Yuhua District 735 Nanjing, Jiangsu 210012 736 China 738 Email: bill.wu@huawei.com 739 Chong Feng 740 Huawei 742 Email: frank.fengchong@huawei.com 744 Rohit R Ranade 745 Huawei 746 Divyashree Techno Park, Whitefield 747 Bangalore, Karnataka 560066 748 India 750 Email: rohitrranade@huawei.com