idnits 2.17.1 draft-ietf-rtgwg-arp-yang-model-03.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [BCP 14], but that reference does not seem to mention RFC 2119 either. -- The document date (November 3, 2019) is 1629 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: 'BCP 14' is mentioned on line 118, but not defined ** Downref: Normative reference to an Unknown state RFC: RFC 1027 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG F. Zheng 3 Internet-Draft B. Wu, Ed. 4 Intended status: Standards Track Huawei 5 Expires: May 6, 2020 R. Wilton, Ed. 6 Cisco Systems 7 X. Ding 8 November 3, 2019 10 YANG Data Model for ARP 11 draft-ietf-rtgwg-arp-yang-model-03 13 Abstract 15 This document defines a YANG data model for the management of the 16 Address Resolution Protocol (ARP). It extends the basic ARP 17 functionality contained in the ietf-ip YANG data model, defined in 18 RFC 8344, to provide management of optional ARP features and 19 statistics. 21 The YANG data model in this document conforms to the Network 22 Management Datastore Architecture defined in RFC 8342. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 6, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 63 3.1. ARP Dynamic Learning . . . . . . . . . . . . . . . . . . 4 64 3.2. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Gratuitous ARP . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. ARP Data Model . . . . . . . . . . . . . . . . . . . . . 5 67 4. ARP YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. Configured static ARP Entry . . . . . . . . . . . . . . . 11 70 5.2. Configuration of proxy ARP and gratuitous ARP . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Basic ARP functionality is supported by the ietf-ip YANG data model, 82 defined in [RFC8344]. This document defines a YANG [RFC7950] data 83 model that extends the basic ARP YANG support to also cover optional 84 ARP features, and ARP related statistics to aid network monitoring 85 and troubleshooting. 87 This model defines YANG configuration and operational state data 88 nodes both for ARP related functionality formally specified in other 89 RFCs (such as [RFC8344] and [RFC1027]), but also for common ARP 90 behaviour that is often supported on network devices. 92 Where necessary, the expected behaviour of the YANG data nodes is 93 defined in the YANG model, and this document. 95 The YANG modules in this document conform to the Network Management 96 Datastore Architecture (NMDA) [RFC8342]. 98 Editorial Note: (To be removed by RFC Editor) 100 This draft contains several placeholder values that need to be 101 replaced with finalized values at the time of publication. Please 102 apply the following replacements: 104 o "XXXX" --> the assigned RFC value for this draft both in this 105 draft and in the YANG models under the revision statement. 107 o The "revision" date in model, in the format XXXX-XX-XX, needs to 108 be updated with the date the draft gets approved. The date also 109 needs to get reflected on the line with . 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 The following terms are defined in [RFC8342] and are not redefined 120 here: 122 o client 124 o server 126 o configuration data 128 o system state 130 o state data 132 o intended configuration 134 o running configuration datastore 136 o operational state datastore 138 The following terms are defined in [RFC7950] and are not redefined 139 here: 141 o augment 143 o data model 145 o data node 146 The terminology for describing YANG data models is found in 147 [RFC7950]. 149 1.2. Tree Diagrams 151 Tree diagrams used in this document follow the notation defined in 152 [RFC8340] 154 2. Problem Statement 156 Neither ARP [RFC0826], nor Proxy-ARP [RFC1027], define standard 157 network management configuration models. Instead, network equipment 158 vendors have implemented their own bespoke configuration interfaces 159 and models. 161 Network operators benefit from having common network management 162 models defined that can be implemented by multiple network equipment 163 manufacturers. This simplifies the operation and management of 164 network devices. 166 Some, but not all, required ARP functionality has been defined in 167 ietf-ip.yang ([RFC8344]). Providing a standard YANG model that 168 models these optional ARP features, that are fairly widely 169 implemented by network equipment manufacturers , and used by network 170 operators, is beneficial to the general goal of interoperability in 171 the networking industry. 173 3. Design of the Data Model 175 This data model intends to describe the processing that a protocol 176 finds the hardware address, also known as Media Access Control (MAC) 177 address, of a host from its known IP address. These tasks include, 178 but are not limited to, configuring dynamic ARP learning, proxy ARP, 179 gratuitous ARP. There are two kind of ARP configurations: global ARP 180 configuration, which is across all interfaces on the device, and per 181 interface ARP configuration. 183 3.1. ARP Dynamic Learning 185 As defined in [RFC0826], ARP caching is the method of storing network 186 addresses and the associated data-link addresses in memory for a 187 period of time as the addresses are learned. This minimizes the use 188 of valuable network resources to broadcast for the same address each 189 time a datagram is sent. 191 There are static ARP cache entries and dynamic ARP cache entries. 192 Static entries, are manually configured and kept in the cache table 193 on a permanent basis which are defined in the ipv4 neighbor list for 194 each interface in [RFC8344]. Dynamic entries are added by vendor 195 software, kept for a period of time, and then removed. We can 196 specify how long an entry remains in the ARP cache. If we specify a 197 timeout of 0 seconds, entries are never cleared from the ARP cache. 199 3.2. Proxy ARP 201 Proxy ARP, defined in [RFC1027], allows a router to respond to ARP 202 requests on behalf of another machine that is not on the same local 203 subnet, offering its own Ethernet media access control (MAC) address. 204 By replying in such a way, the router then takes responsibility for 205 routing packets to the intended destination. 207 In the case of certain data center network virtualization, as 208 specified in [RFC8014], the proxy ARP can be extended to intercept 209 all ARP requests, including source and target IP addresses in 210 different subnets, and those ARP requests in the same subnet to 211 suppress ARP handling. 213 3.3. Gratuitous ARP 215 Gratuitous ARP enables a device to send an ARP Request packet using 216 its own IP address as the destination address. Gratuitous ARP 217 provides the following functions: 219 o Checks duplicate IP addresses: [RFC5227] uses gratuitous ARP to 220 help detect IP conflicts. When a device receives an ARP request 221 containing a source IP that matches its own, then it knows there 222 is an IP conflict. 224 o Advertises a new MAC address: Also in [RFC5227], if the MAC 225 address of a host changes because its network adapter is replaced, 226 the host sends a gratuitous ARP packet to notify all hosts of the 227 change before the ARP entry is aged out. 229 o Notifies an active/standby switchover in a [RFC5798] VRRP backup 230 group: After an active/standby switchover, the master router sends 231 a gratuitous ARP packet in the VRRP backup group to notify the 232 switchover. 234 3.4. ARP Data Model 236 This document defines the YANG module "ietf-arp", which has the 237 following structure: 239 module: ietf-arp 240 +--rw arp 241 +--rw dynamic-learning? boolean 243 augment /if:interfaces/if:interface/ip:ipv4: 244 +--rw arp 245 +--rw expiry-time? uint32 246 +--rw dynamic-learning? boolean 247 +--rw proxy-arp 248 | +--rw mode? enumeration 249 +--rw gratuitous-arp 250 | +--rw enable? boolean 251 | +--rw interval? uint32 252 +--ro statistics 253 +--ro in-requests-pkts? yang:counter32 254 +--ro in-replies-pkts? yang:counter32 255 +--ro in-gratuitous-pkts? yang:counter32 256 +--ro out-requests-pkts? yang:counter32 257 +--ro out-replies-pkts? yang:counter32 258 +--ro out-gratuitous-pkts? yang:counter32 259 augment /if:interfaces/if:interface/ip:ipv4/ip:neighbor: 260 +--ro remaining-expiry-time? uint32 262 4. ARP YANG Module 264 This section presents the ARP YANG module defined in this document. 266 This module imports definitions from Common YANG Data Types 267 [RFC6991], A YANG Data Model for Interface Management [RFC8343], and 268 A YANG Data Model for IP Management [RFC8344]. 270 file "ietf-arp@2019-11-04.yang" 272 module ietf-arp { 273 yang-version 1.1; 274 namespace "urn:ietf:params:xml:ns:yang:ietf-arp"; 275 prefix arp; 277 import ietf-yang-types { 278 prefix yang; 279 reference "RFC 6991: Common YANG Data Types"; 280 } 281 import ietf-interfaces { 282 prefix if; 283 reference "RFC 8343: A Yang Data Model for Interface Management"; 284 } 285 import ietf-ip { 286 prefix ip; 287 reference "RFC 8344: A Yang Data Model for IP Management"; 288 } 290 organization 291 "IETF Routing Area Working Group (rtgwg)"; 292 contact 293 "WG Web: 294 WG List: 295 Author: Feng Zheng 296 habby.zheng@huawei.com 297 Editor: Bo Wu 298 lana.wubo@huawei.com 299 Editor: Robert Wilton 300 rwilton@cisco.com 301 Author: Xiaojian Ding 302 wjswsl@163.com"; 303 description 304 "Address Resolution Protocol (ARP) management, which includes 305 static ARP configuration, dynamic ARP learning, ARP entry query, 306 and packet statistics collection. 308 Copyright (c) 2019 IETF Trust and the persons identified as 309 authors of the code. All rights reserved. 311 Redistribution and use in source and binary forms, with or 312 without modification, is permitted pursuant to, and subject 313 to the license terms contained in, the Simplified BSD License 314 set forth in Section 4.c of the IETF Trust's Legal Provisions 315 Relating to IETF Documents 316 (http://trustee.ietf.org/license-info). 318 This version of this YANG module is part of RFC XXXX; see the 319 RFC itself for full legal notices."; 321 revision 2019-11-04 { 322 description 323 "Init revision"; 324 reference "RFC XXXX: A Yang Data Model for ARP"; 325 } 327 container arp { 328 description 329 "Address Resolution Protocol (ARP)"; 330 leaf dynamic-learning { 331 type boolean; 332 default "true"; 333 description 334 "Controls the default ARP learning behavior on all 335 interfaces on the device, unless explicit overridden by 336 the per-interface dynamic-learning leaf: 337 true - dynamic learning is enabled on all interfaces by 338 default, 339 false - dynamic learning is disabled on all interfaces by 340 default"; 341 reference "RFC826: An Ethernet Address Resolution Protocol"; 342 } 343 } 344 augment "/if:interfaces/if:interface/ip:ipv4" { 345 description 346 "Augment interfaces with ARP configuration and state."; 347 container arp { 348 description 349 "Address Resolution Protocol (ARP) related configuration 350 and state"; 351 leaf expiry-time { 352 type uint32 { 353 range "30..86400"; 354 } 355 units "seconds"; 356 description 357 "Aging time of a received dynamic ARP entry before it is 358 removed from the cache."; 359 } 360 leaf dynamic-learning { 361 type boolean; 362 description 363 "Controls whether dynamic ARP learning is enabled on the 364 interface. If not configured, it defaults to the behavior 365 specified in the per-device /arp/dynamic-learning leaf. 367 true - dynamic learning is enabled 368 false - dynamic learning is disabled"; 369 } 370 container proxy-arp { 371 description 372 "Configuration parameters for proxy ARP"; 373 leaf mode { 374 type enumeration { 375 enum disabled { 376 description 377 "The system only responds to ARP requests that 378 specify a target address configured on the local 379 interface."; 380 } 381 enum remote-only { 382 description 383 "The system only responds to ARP requests when the 384 sender and target IP addresses are in different 385 subnets."; 386 } 387 enum all { 388 description 389 "The system responds to ARP requests where the sender 390 and target IP addresses are in different subnets, as 391 well as those where they are in the same subnet."; 392 } 393 } 394 default "disabled"; 395 description 396 "When set to a value other than 'disable', the local 397 system should respond to ARP requests that are for 398 target addresses other than those that are configured on 399 the local subinterface using its own MAC address as the 400 target hardware address. If the 'remote-only' value is 401 specified, replies are only sent when the target address 402 falls outside the locally configured subnets on the 403 interface, whereas with the 'all' value, all requests, 404 regardless of their target address are replied to."; 405 reference 406 "RFC1027: Using ARP to Implement Transparent Subnet 407 Gateways"; 408 } 409 } 410 container gratuitous-arp { 411 description "Configure gratuitous ARP."; 412 reference "RFC5227: IPv4 Address Conflict Detection"; 413 leaf enable { 414 type boolean; 415 description 416 "Enable or disable sending gratuitous ARP packet on the 417 interface. 419 The default behaviour is device specific, and a 420 deviation could used to to specify a device specific 421 default."; 422 } 423 leaf interval { 424 type uint32 { 425 range "1..86400"; 426 } 427 units "seconds"; 428 description 429 "The interval, in seconds, between sending gratuitous ARP 430 packet on the interface. 432 The default behaviour is device specific, and a 433 deviation could used to to specify a device specific 434 default."; 435 } 436 } 437 container statistics { 438 config false; 439 description 440 "ARP per-interface packet statistics 442 For all ARP interface counters, discontinuities in the 443 value can occur at re-initialization of the management 444 system and at other times as indicated by the value of 445 '../../statistics/discontinuity-time' in the 446 ietf-interfaces YANG module."; 448 leaf in-requests-pkts { 449 type yang:counter32; 450 description 451 "The number of ARP request packets received on this 452 interface."; 453 } 455 leaf in-replies-pkts { 456 type yang:counter32; 457 description 458 "The number of ARP reply packets received on this 459 interface."; 460 } 462 leaf in-gratuitous-pkts { 463 type yang:counter32; 464 description 465 "The number of gratuitous ARP packets received on this 466 interface."; 467 } 469 leaf out-requests-pkts { 470 type yang:counter32; 471 description 472 "The number of ARP request packets sent on this 473 interface."; 474 } 476 leaf out-replies-pkts { 477 type yang:counter32; 478 description 479 "The number of ARP reply packets sent on this 480 interface."; 481 } 483 leaf out-gratuitous-pkts { 484 type yang:counter32; 485 description 486 "The number of gratuitous ARP packets sent on this 487 interface."; 488 } 489 } 490 } 491 } 493 augment "/if:interfaces/if:interface/ip:ipv4/ip:neighbor" { 494 description 495 "Augment IPv4 neighbor list with ARP expiry time."; 496 leaf remaining-expiry-time { 497 type uint32; 498 units "seconds"; 499 config false; 500 description 501 "The number of seconds until the dynamic ARP entry expires 502 and is removed from the ARP cache."; 503 } 504 } 505 } 507 5. Data Model Examples 509 This section presents two simple ARP configuration examples: 511 5.1. Configured static ARP Entry 513 This example illustrates the configuration for a static ARP entry for 514 peer 192.0.2.1 with MAC address 00:00:5E:00:53:AB using the model 515 defined in [RFC8344]. 517 518 521 522 eth0 523 ianaift:ethernetCsmacd 524 526 527 528 529 192.0.2.1 530 00:00:5E:00:53:AB 531 532 533 534 536 5.2. Configuration of proxy ARP and gratuitous ARP 538 This example illustrates the configuration of ARP entry expiry time, 539 proxy ARP in 'remote-only' mode, and enabling gratuitous ARP with an 540 interval of 10 minutes. 542 543 546 547 eth0 548 ianaift:ethernetCsmacd 549 551 552 553 554 1200 555 556 remote-only 557 558 559 true 560 600 561 562 563 564 565 567 6. IANA Considerations 569 This document registers a URI in the IETF XML registry [RFC3688]. 570 Following the format in [RFC3688], the following registration is 571 requested to be made: 573 URI: urn:ietf:params:xml:ns:yang:ietf-arp 574 Registrant Contact: The RTGWG WG of the IETF. 575 XML: N/A, the requested URI is an XML namespace. 577 This document registers a YANG module in the YANG Module Names 578 registry [RFC6020]. 580 Name: ietf-arp 581 Namespace: urn:ietf:params:xml:ns:yang:ietf-arp 582 Prefix: arp 583 Reference: RFC XXXX 585 7. Security Considerations 587 The YANG module specified in this document defines a schema for data 588 that is designed to be accessed via network management protocols such 589 as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF 590 layer is the secure transport layer, and the mandatory-to-implement 591 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 592 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 593 transport is TLS [RFC8446]. 595 The NETCONF access control model [RFC8341] provides the means to 596 restrict access for particular NETCONF or RESTCONF users to a 597 preconfigured subset of all available NETCONF or RESTCONF protocol 598 operations and content.. 600 There are a number of data nodes defined in this YANG module that are 601 writable/creatable/deletable (i.e., config true, which is the 602 default). These data nodes may be considered sensitive or vulnerable 603 in some network environments. Write operations (e.g., edit-config) 604 to these data nodes without proper protection can have a negative 605 effect on network operations.These are the subtrees and data nodes 606 and their sensitivity/vulnerability: 608 arp/dynamic-learning: This leaf is used to enable ARP dynamic 609 learning on all interfaces. ARP dynamic learning could allow an 610 attacker to inject spoofed traffic into the network, e.g. denial- 611 of-service attack. 613 interface/ipv4/arp/proxy-arp: These leaves are used to enable 614 proxy ARP on an interface. They could allow traffic to be mis- 615 configured (denial-of-service attack). 617 interface/ipv4/arp/gratuitous-arp: These leaves are used to enable 618 sending gratuitous ARP packet on an interface. This configuration 619 could allow an attacker to inject spoofed traffic into the 620 network, e.g. man-in-the-middle attack. The default value for 621 this data node is device specific, and hence users of this model 622 MUST understand whether or not gratutious ARP is enabled and 623 whether this could constitute a security risk. 625 8. Acknowledgments 627 The authors wish to thank Alex Campbell, Reshad Rahman, Qin Wu, Tom 628 Petch, Jeffrey Haas, and others for their helpful comments. 630 9. References 632 9.1. Normative References 634 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 635 Converting Network Protocol Addresses to 48.bit Ethernet 636 Address for Transmission on Ethernet Hardware", STD 37, 637 RFC 826, DOI 10.17487/RFC0826, November 1982, 638 . 640 [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to 641 implement transparent subnet gateways", RFC 1027, 642 DOI 10.17487/RFC1027, October 1987, 643 . 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, 647 DOI 10.17487/RFC2119, March 1997, 648 . 650 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 651 DOI 10.17487/RFC3688, January 2004, 652 . 654 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 655 DOI 10.17487/RFC5227, July 2008, 656 . 658 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 659 the Network Configuration Protocol (NETCONF)", RFC 6020, 660 DOI 10.17487/RFC6020, October 2010, 661 . 663 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 664 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 665 . 667 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 668 RFC 6991, DOI 10.17487/RFC6991, July 2013, 669 . 671 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 672 RFC 7950, DOI 10.17487/RFC7950, August 2016, 673 . 675 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 676 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 677 May 2017, . 679 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 680 and R. Wilton, "Network Management Datastore Architecture 681 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 682 . 684 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 685 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 686 . 688 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 689 RFC 8344, DOI 10.17487/RFC8344, March 2018, 690 . 692 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 693 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 694 . 696 9.2. Informative References 698 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 699 Version 3 for IPv4 and IPv6", RFC 5798, 700 DOI 10.17487/RFC5798, March 2010, 701 . 703 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 704 and A. Bierman, Ed., "Network Configuration Protocol 705 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 706 . 708 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 709 Narten, "An Architecture for Data-Center Network 710 Virtualization over Layer 3 (NVO3)", RFC 8014, 711 DOI 10.17487/RFC8014, December 2016, 712 . 714 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 715 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 716 . 718 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 719 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 720 . 722 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 723 Access Control Model", STD 91, RFC 8341, 724 DOI 10.17487/RFC8341, March 2018, 725 . 727 Authors' Addresses 729 Feng Zheng 730 Huawei 731 101 Software Avenue, Yuhua District 732 Nanjing, Jiangsu 210012 733 China 735 Email: habby.zheng@huawei.com 737 Bo Wu (editor) 738 Huawei 740 Email: lana.wubo@huawei.com 742 Robert Wilton (editor) 743 Cisco Systems 745 Email: rwilton@cisco.com 747 Xiaojian Ding 749 Email: wjswsl@163.com