idnits 2.17.1 draft-ding-rtgwg-arp-yang-model-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 17 characters in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 182 has weird spacing: '...address yan...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 27, 2018) is 2243 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: 'RFC826' is mentioned on line 77, but not defined == Missing Reference: 'RFC6536' is mentioned on line 678, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Unused Reference: 'RFC0826' is defined on line 731, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG X. Ding 3 Internet-Draft F. Zheng 4 Intended status: Standards Track Huawei 5 Expires: August 31, 2018 R. Wilton 6 Cisco Systems 7 February 27, 2018 9 YANG Data Model for ARP 10 draft-ding-rtgwg-arp-yang-model-01 12 Abstract 14 This document defines a specification of one YANG module and one 15 submodule. Together they form the Address Resolution Protocol (ARP) 16 data model that performs as a guideline for configuring ARP 17 capabilities on a system. It is intended these modules be used by 18 service providers who manipulate devices from different vendors in a 19 standard way. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 31, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 (https://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 respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 60 3.1. ietf-arp Module . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. ietf-arp-dynamic-learning Submodule . . . . . . . . . . . 5 62 4. ARP YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. ARP Dynamic Learning Submodule . . . . . . . . . . . . . 9 64 5. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 14 65 5.1. Static ARP Entries . . . . . . . . . . . . . . . . . . . 14 66 5.2. ARP Dynamic Learning . . . . . . . . . . . . . . . . . . 14 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 71 8.2. Informative References . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 This document defines a YANG [RFC6020] data model for Address 77 Resolution Protocol [RFC826] implementation and identification of 78 some common properties within a device containing a Network 79 Configuration Protocol (NETCONF) server. Devices that are managed by 80 NETCONF and perhaps other mechanisms have common properties that need 81 to be configured and monitored in a standard way. 83 This document contains a specification of the following YANG modules: 85 o The "ietf-arp" module provides generic abilities of a ARP data 86 model. This module is used for global ARP configurations. 88 o The submodule "ietf-arp-dynamic-learning" augments the "ietf- 89 interfaces" [I-D.ietf-netmod-rfc7223bis] and "ietf-ip" [I-D.ietf- 90 netmod-rfc7277bis] modules with additional data specification to 91 ARP confifuration on interfaces. 93 These YANG modules cover configuration of system parameters of ARP, 94 such as static ARP entries, timeout for dynamic ARP entries, 95 interface ARP, proxy ARP, and so on. They also provide information 96 about running state of ARP implementations. 98 1.1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14, [RFC2119]. 105 The following terms are defined in [RFC6241] and are not redefined 106 here: 108 o client 110 o configuration data 112 o server 114 o state data 116 1.2. Tree Diagrams 118 A simplified graphical representation of the data model is presented 119 in Section 3. 121 o Brackets "[" and "]" enclose list keys. 123 o Abbreviations before data node names: "rw" means configuration 124 (read-write) and "ro" state data (read-only). 126 o Symbols after data node names: "?" means an optional node, "!" 127 means a presence container, and "*" denotes a list and leaf-list. 129 o Parentheses enclose choice and case nodes, and case nodes are also 130 marked with a colon (":"). 132 o Ellipsis ("...") stands for contents of subtrees that are not 133 shown. 135 2. Problem Statement 137 This document defines a YANG [RFC7950] configuration data model that 138 may be used to configure the ARP feature running on a system. YANG 139 model can be used with network management protocols such as NETCONF 140 [RFC6241] to install, manipulate, and delete the configuration of 141 network devices. 143 The data model makes use of the YANG "feature" construct which allows 144 implementations to support only those ARP features that lie within 145 their capabilities. It is intended this model be used by service 146 providers who manipulate devices from different vendors in a standard 147 way. 149 This model can be used to configure the ARP applications for 150 discovering the link layer address associated with a given Internet 151 layer address. 153 3. Design of the Data Model 155 This data model intends to describe the processing that a protocol 156 finds the hardware address, also known as Media Access Control (MAC) 157 address, of a host from its known IP address. These tasks include, 158 but are not limited to, adding a static entry in the ARP cache, 159 configuring ARP cache entry timeout, and clearing dynamic entries 160 from the ARP cache. 162 The ARP data model consists of one YANG module and one submodule. 163 The first module, "ietf-arp", defines the generic abilities of ARP 164 configurations. Its submodule, "ietf-arp-dynamic-learning", augments 165 the "ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and "ietf-ip" [I- 166 D.ietf-netmod-rfc7277bis] modules with additional data specification 167 to ARP confifuration on interfaces. 169 3.1. ietf-arp Module 171 This module has one top level container, ARP, which consists of two 172 second level containers. Each of these second level containers 173 describes a particular category of ARP handling, such as defining 174 static mapping between an IP address (32-bit address) and a Media 175 Access Control (MAC) address (48-bit address). 177 module: ietf-arp 178 +--rw arp 179 +--rw global-static-table {global-static-table}? 180 | +--rw static-entry* [ip-address] 181 | +--rw ip-address inet:ipv4-address-no-zone 182 | +--rw mac-address yang:mac-address 183 +--ro statistics 184 +--ro in-requests-pkts? uint64 185 +--ro in-replies-pkts? uint64 186 +--ro in-gratuitous-pkts? uint64 187 +--ro out-requests-pkts? uint64 188 +--ro out-replies-pkts? uint64 189 +--ro out-gratuitous-pkts? uint64 190 +--ro in-drops? uint64 191 +--ro in-total? uint64 192 +--ro out-total? uint64 193 +--ro all-dynamic-pkts? uint64 194 +--ro all-static-pkts? uint64 196 3.2. ietf-arp-dynamic-learning Submodule 198 submodule: ietf-arp-dynamic-learning (belongs-to ietf-arp) 199 augment /if:interfaces/if:interface: 200 +--rw arp-dynamic-learning 201 +--rw expire-time? uint32 202 +--rw learn-disable? boolean 203 +--rw proxy-enable? boolean 204 +--rw if-limit* [vlan-id] 205 | +--rw vlan-id uint16 206 | +--rw limit-number uint32 207 | +--rw threshold-value? uint32 208 +--rw probe 209 | +--rw interval? uint8 210 | +--rw times? uint8 211 | +--rw unicast? boolean 212 +--rw gratuitous 213 | +--rw gratuitous-enable? boolean 214 | +--rw interval? uint32 215 | +--rw drop? boolean 216 +--ro statistics 217 +--ro in-requests-pkts? uint64 218 +--ro in-replies-pkts? uint64 219 +--ro in-gratuitous-pkts? uint64 220 +--ro out-requests-pkts? uint64 221 +--ro out-replies-pkts? uint64 222 +--ro out-gratuitous-pkts? uint64 223 augment /if:interfaces/if:interface/ip:ipv4/ip:neighbor: 224 +--ro remaining-expire-time? uint32 226 4. ARP YANG Module 228 This section presents the ARP YANG module defined in this document. 229 This YANG module imports typedefs from [RFC6991]. 231 file "ietf-arp@2018-01-27.yang" 232 module ietf-arp { 233 namespace "urn:ietf:params:xml:ns:yang:ietf-arp"; 234 prefix arp; 236 import ietf-inet-types { 237 prefix inet; 238 } 239 import ietf-yang-types { 240 prefix yang; 241 } 243 organization 244 "IETF Routing Area Working Group (rtgwg)"; 245 contact 246 "WG Web: 247 WG List: 248 Editor: Xiaojian Ding 249 dingxiaojian1@huawei.com 250 Editor: Feng Zheng 251 habby.zheng@huawei.com 252 Editor: Robert Wilton 253 rwilton@cisco.com"; 254 description 255 "Address Resolution Protocol (ARP) management, which includes 256 static ARP configuration, dynamic ARP learning, ARP entry query, 257 and packet statistics collection."; 259 revision 2017-10-18 { 260 description 261 "Init revision"; 262 reference "RFC XXX: ARP (Address Resolution Protocol) YANG data model."; 263 } 265 feature global-static-table { 266 description 267 "This feature indicates that the device allows static entries 268 to be configured globally."; 269 } 271 container arp { 272 description 273 "Address Resolution Protocol (ARP) management, which includes 274 static ARP configuration, dynamic ARP learning, ARP entry 275 query, and packet statistics collection."; 276 container global-static-table { 277 if-feature "global-static-table"; 278 description 279 "Set a global static ARP entry, which is independent of the interface."; 280 list static-entry { 281 key "ip-address"; 282 description 283 "List of ARP static entries that can be configured globally."; 284 leaf ip-address { 285 type inet:ipv4-address-no-zone; 286 description 287 "IP address, in dotted decimal notation."; 288 } 289 leaf mac-address { 290 type yang:mac-address; 291 mandatory true; 292 description 293 "MAC address in the format of H-H-H, in which H is 294 a hexadecimal number of 1 to 4 bits."; 295 } 296 } 297 } 298 container statistics { 299 config false; 300 description 301 "List of ARP packet statistics."; 302 leaf in-requests-pkts { 303 type uint64; 304 description 305 "Total ARP requests received"; 306 } 307 leaf in-replies-pkts { 308 type uint64; 309 description 310 "Total ARP replies received"; 311 } 312 leaf in-gratuitous-pkts { 313 type uint64; 314 description 315 "Total gratuitous ARP received"; 316 } 317 leaf out-requests-pkts { 318 type uint64; 319 description 320 "Total ARP requests sent"; 321 } 322 leaf out-replies-pkts { 323 type uint64; 324 description 325 "Total ARP replies sent"; 326 } 327 leaf out-gratuitous-pkts { 328 type uint64; 329 description 330 "Total gratuitous ARP sent"; 331 } 332 leaf in-drops { 333 type uint64 { 334 range "0..4294967294"; 335 } 336 description 337 "Number of ARP packets discarded."; 338 } 339 leaf in-total { 340 type uint64 { 341 range "0..4294967294"; 342 } 343 description 344 "Total number of ARP received packets."; 345 } 346 leaf out-total { 347 type uint64 { 348 range "0..4294967294"; 349 } 350 description 351 "Total number of ARP sent packets."; 352 } 353 leaf all-dynamic-pkts { 354 type uint64 { 355 range "0..4294967294"; 356 } 357 description 358 "Number of dynamic ARP packets count."; 359 } 360 leaf all-static-pkts { 361 type uint64 { 362 range "0..4294967294"; 363 } 364 description 365 "Number of static ARP packets count."; 366 } 367 } 368 } 369 } 370 372 4.1. ARP Dynamic Learning Submodule 374 file "ietf-arp-dynaminc-learning@2018-01-27.yang" 375 submodule ietf-arp-dynamic-learning { 376 yang-version 1.1; 377 belongs-to ietf-arp { 378 prefix arp; 379 } 381 import ietf-interfaces { 382 prefix if; 383 description 384 "A Network Management Datastore Architecture (NMDA) 385 compatible version of the ietf-interfaces module 386 is required."; 387 } 388 import ietf-ip { 389 prefix ip; 390 description 391 "A Network Management Datastore Architecture (NMDA) 392 compatible version of the ietf-ip module is 393 required."; 394 } 396 organization 397 "IETF Routing Area Working Group (rtgwg)"; 398 contact 399 "WG Web: 400 WG List: 401 Editor: Xiaojian Ding 402 dingxiaojian1@huawei.com 403 Editor: Feng Zheng 404 habby.zheng@huawei.com 405 Editor: Robert Wilton 406 rwilton@cisco.com"; 407 description 408 "This YANG module augments 'ietf-if' and 'ietf-ip' 409 modules with parameters for ARP configuration on interfaces. 410 The model fully conforms to the Network Management 411 Datastore Architecture (NMDA). 413 Copyright (c) 2017 IETF Trust and the persons 414 identified as authors of the code. All rights reserved. 416 Redistribution and use in source and binary forms, with or 417 without modification, is permitted pursuant to, and subject 418 to the license terms contained in, the Simplified BSD License 419 set forth in Section 4.c of the IETF Trust's Legal Provisions 420 Relating to IETF Documents 421 (http://trustee.ietf.org/license-info). 423 This version of this YANG module is part of RFC XXXX; see 424 the RFC itself for full legal notices."; 426 revision 2018-01-27 { 427 description 428 "Initial revision."; 429 reference "RFC XXX: ARP (Address Resolution Protocol) YANG data model"; 430 } 432 augment "/if:interfaces/if:interface" { 433 description 434 "Augment interface configuration with parameters of ARP."; 435 container arp-dynamic-learning { 436 description 437 "Support for ARP configuration on interfaces."; 438 leaf expire-time { 439 type uint32 { 440 range "60..86400"; 441 } 442 units "second"; 443 description 444 "Aging time of a dynamic ARP entry."; 445 } 446 leaf learn-disable { 447 type boolean; 448 default "false"; 449 description 450 "Whether dynamic ARP learning is disabled. If the value 451 is True, dynamic ARP learning is disabled. If the value 452 is False, dynamic ARP learning is enabled."; 453 } 454 leaf proxy-enable { 455 type boolean; 456 default "false"; 457 description 458 "Enable proxy ARP."; 459 } 460 list if-limit { 461 key "vlan-id"; 462 description 463 "Maximum number of dynamic ARP entries that an 464 interface can learn. If the number of ARP entries that 465 an interface can learn changes and the number of the 466 learned ARP entries exceeds the changed value, the 467 interface cannot learn additional ARP entries. The 468 system prompts you to delete the excess ARP entries."; 469 leaf vlan-id { 470 type uint16 { 471 range "0..4094"; 472 } 473 description 474 "ID of the VLAN where ARP learning is restricted. 475 This parameter can be set only on Layer 2 interfaces 476 and sub-interfaces. Ethernet, GE, VE, and Eth-Trunk 477 interfaces can be both Layer 3 and Layer 2 478 interfaces. When they work in Layer 3 mode, they 479 cannot have VLANs configured. When they work in Layer 480 2 mode, they must have VLANs configured. Ethernet, 481 GE, and Eth-Trunk sub-interfaces can be both common 482 and QinQ sub-interfaces. "; 483 } 484 leaf limit-number { 485 type uint32 { 486 range "1..65536"; 487 } 488 mandatory true; 489 description 490 "Maximum number of dynamic ARP entries that an 491 interface can learn."; 492 } 493 leaf threshold-value { 494 type uint32 { 495 range "60..100"; 496 } 497 must "not(not(../limit-number))" { 498 description 499 "Upper boundary must be higher than lower boundary."; 500 } 501 description 502 "Alarm-Threshold for Maximum number of ARP entries 503 that an interface can learn."; 504 } 505 } 506 container probe { 507 description 508 "Common configuration parameters for all ARP probe."; 509 leaf interval { 510 type uint8 { 511 range "1..5"; 512 } 513 units "second"; 514 description 515 "Interval for detecting dynamic ARP entries."; 516 } 517 leaf times { 518 type uint8 { 519 range "0..10"; 520 } 521 description 522 "Number of aging probe attempts for a dynamic ARP entry. 523 If a device does not receive an ARP reply message after 524 the number of aging probe attempts reaches a specified 525 number,thedynamic ARP entry is deleted."; 526 } 527 leaf unicast { 528 type boolean; 529 default "false"; 530 description 531 "Send unicast ARP aging probe messages for a dynamic ARP 532 entry."; 533 } 534 } 535 container gratuitous { 536 description 537 "Configure gratuitous ARP."; 538 leaf gratuitous-enable { 539 type boolean; 540 default "false"; 541 description 542 "Enable or disable sending gratuitous-arp packet on 543 interface."; 544 } 545 leaf interval { 546 type uint32 { 547 range "1..86400"; 548 } 549 units "second"; 550 description 551 "The interval of sending gratuitous-arp packet on the 552 interface."; 553 } 554 leaf drop { 555 type boolean; 556 default "false"; 557 description 558 "Drop the receipt of gratuitous ARP packets on the interface."; 559 } 560 } 561 container statistics { 562 config false; 563 description 564 "IP ARP Statistics information on interfaces"; 565 leaf in-requests-pkts { 566 type uint64; 567 description 568 "Total ARP requests received"; 569 } 570 leaf in-replies-pkts { 571 type uint64; 572 description 573 "Total ARP replies received"; 574 } 575 leaf in-gratuitous-pkts { 576 type uint64; 577 description 578 "Total gratuitous ARP received"; 579 } 580 leaf out-requests-pkts { 581 type uint64; 582 description 583 "Total ARP requests sent"; 584 } 585 leaf out-replies-pkts { 586 type uint64; 587 description 588 "Total ARP replies sent"; 589 } 590 leaf out-gratuitous-pkts { 591 type uint64; 592 description 593 "Total gratuitous ARP sent"; 594 } 595 } 596 } 597 } 598 augment "/if:interfaces/if:interface/ip:ipv4/ip:neighbor" { 599 description 600 "Augment neighbor list with parameters of ARP, 601 eg., support for remaining expire time query on interfaces."; 602 leaf remaining-expire-time { 603 type uint32; 604 config false; 605 description 606 "Remaining expire time of a dynamic ARP entry. "; 607 } 608 } 609 } 610 612 5. Data Model Examples 614 This section presents a simple but complete example of configuring 615 static ARP entries and dynamic learning, based on the YANG modules 616 specified in Section 4. 618 5.1. Static ARP Entries 620 Requirement: 621 Enable static ARP entry global configuration (not rely on interface). 622 623 624 625 10.2.2.3 626 00e0-fc01-0000 627 628 630 Requirement: 631 Enable static ARP entry configuration on interface (defined in 632 draft [I-D.ietf-netmod-rfc7277bis]). 633 634 635 636 __public__ 637 10.2.2.3 638 00e0-fc01-0000 639 GE1/0/1 640 641 643 5.2. ARP Dynamic Learning 644 Requirement: 645 Enable ARP dynamic learning configuration. 647 648 649 GE1/0/1 650 1200 651 false 652 false 653 654 3 655 65535 656 80 657 658 659 5 660 3 661 false 662 663 664 false 665 60 666 false 667 668 670 6. Security Considerations 672 The YANG module defined in this document is designed to be accessed 673 via YANG based management protocols, such as NETCONF [RFC6241] and 674 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 675 implement secure transport layers (e.g., SSH, TLS) with mutual 676 authentication. 678 The NETCONF access control model (NACM) [RFC6536] provides the means 679 to restrict access for particular users to a pre-configured subset of 680 all available protocol operations and content. 682 These are the subtrees and data nodes and their sensitivity/ 683 vulnerability: 685 There are a number of data nodes defined in this YANG module that are 686 writable/creatable/deletable (i.e., config true, which is the 687 default). These data nodes may be considered sensitive or vulnerable 688 in some network environments. Write operations (e.g., edit-config) 689 to these data nodes without proper protection can have a negative 690 effect on network operations. 692 7. Acknowledgments 694 The authors wish to thank Alex Campbell and Reshad Rahman, Qin Wu, 695 many others for their helpful comments. 697 8. References 699 8.1. Normative References 701 [I-D.ietf-netmod-rfc7223bis] 702 Bjorklund, M., "A YANG Data Model for Interface 703 Management", draft-ietf-netmod-rfc7223bis-03 (work in 704 progress), January 2018. 706 [I-D.ietf-netmod-rfc7277bis] 707 Bjorklund, M., "A YANG Data Model for IP Management", 708 draft-ietf-netmod-rfc7277bis-03 (work in progress), 709 January 2018. 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, 713 DOI 10.17487/RFC2119, March 1997, 714 . 716 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 717 the Network Configuration Protocol (NETCONF)", RFC 6020, 718 DOI 10.17487/RFC6020, October 2010, 719 . 721 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 722 RFC 6991, DOI 10.17487/RFC6991, July 2013, 723 . 725 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 726 RFC 7950, DOI 10.17487/RFC7950, August 2016, 727 . 729 8.2. Informative References 731 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 732 Converting Network Protocol Addresses to 48.bit Ethernet 733 Address for Transmission on Ethernet Hardware", STD 37, 734 RFC 826, DOI 10.17487/RFC0826, November 1982, 735 . 737 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 738 and A. Bierman, Ed., "Network Configuration Protocol 739 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 740 . 742 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 743 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 744 . 746 Authors' Addresses 748 Xiaojian Ding 749 Huawei 750 101 Software Avenue, Yuhua District 751 Nanjing, Jiangsu 210012 752 China 754 Email: dingxiaojian1@huawei.com 756 Feng Zheng 757 Huawei 758 101 Software Avenue, Yuhua District 759 Nanjing, Jiangsu 210012 760 China 762 Email: habby.zheng@huawei.com 764 Robert Wilton 765 Cisco Systems 767 Email: rwilton@cisco.com