idnits 2.17.1 draft-ietf-rtgwg-arp-yang-model-02.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 10, 2019) is 1875 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 (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG F. Zheng 3 Internet-Draft B. Wu 4 Intended status: Standards Track Huawei 5 Expires: September 11, 2019 R. Wilton 6 Cisco Systems 7 X. Ding 8 March 10, 2019 10 YANG Data Model for ARP 11 draft-ietf-rtgwg-arp-yang-model-02 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 September 11, 2019. 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. Static ARP Entries . . . . . . . . . . . . . . . . . . . 11 70 5.2. ARP Dynamic Learning . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 9.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 RFC 5227, if the MAC address 225 of a host changes because its network adapter is replaced, the 226 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 discontinuity-time? yang:date-and-time 254 +--ro in-requests-pkts? yang:counter32 255 +--ro in-replies-pkts? yang:counter32 256 +--ro in-gratuitous-pkts? yang:counter32 257 +--ro out-requests-pkts? yang:counter32 258 +--ro out-replies-pkts? yang:counter32 259 +--ro out-gratuitous-pkts? yang:counter32 260 augment /if:interfaces/if:interface/ip:ipv4/ip:neighbor: 261 +--ro remaining-expiry-time? uint32 263 4. ARP YANG Module 265 This section presents the ARP YANG module defined in this document. 267 This module imports definitions from Common YANG Data Types 268 [RFC6991], A YANG Data Model for Interface Management [RFC8343], and 269 A YANG Data Model for IP Management [RFC8344]. 271 file "ietf-arp@2019-02-21.yang" 273 module ietf-arp { 274 yang-version 1.1; 275 namespace "urn:ietf:params:xml:ns:yang:ietf-arp"; 276 prefix arp; 278 import ietf-yang-types { 279 prefix yang; 280 reference "RFC 6991: Common YANG Data Types"; 281 } 282 import ietf-interfaces { 283 prefix if; 284 reference "RFC 8343: A Yang Data Model for Interface Management"; 285 } 286 import ietf-ip { 287 prefix ip; 288 reference "RFC 8344: A Yang Data Model for IP Management"; 289 } 291 organization 292 "IETF Routing Area Working Group (rtgwg)"; 293 contact 294 "WG Web: 295 WG List: 296 Editor: Feng Zheng 297 habby.zheng@huawei.com 298 Editor: Bo Wu 299 lana.wubo@huawei.com 300 Editor: Robert Wilton 301 rwilton@cisco.com 302 Editor: Xiaojian Ding 303 wjswsl@163.com"; 304 description 305 "Address Resolution Protocol (ARP) management, which includes 306 static ARP configuration, dynamic ARP learning, ARP entry query, 307 and packet statistics collection. 309 Copyright (c) 2018 IETF Trust and the persons identified as 310 authors of the code. All rights reserved. 312 Redistribution and use in source and binary forms, with or 313 without modification, is permitted pursuant to, and subject 314 to the license terms contained in, the Simplified BSD License 315 set forth in Section 4.c of the IETF Trust's Legal Provisions 316 Relating to IETF Documents 317 (http://trustee.ietf.org/license-info). 319 This version of this YANG module is part of RFC XXXX; see the RFC 320 itself for full legal notices."; 322 revision 2019-02-21 { 323 description 324 "Init revision"; 325 reference "RFC XXXX: A Yang Data Model for ARP"; 326 } 328 container arp { 329 description 330 "Address Resolution Protocol (ARP)"; 331 leaf dynamic-learning { 332 type boolean; 333 default "true"; 334 description 335 "Controls the default ARP learning behavior on all 336 interfaces on the device, unless explicit overridden by 337 the per-interface dynamic-learning leaf: 338 true - dynamic learning is enabled on all interfaces by 339 default, 340 false - dynamic learning is disabled on all interfaces by 341 default"; 342 reference "RFC826: An Ethernet Address Resolution Protocol"; 343 } 344 } 345 augment "/if:interfaces/if:interface/ip:ipv4" { 346 description 347 "Augment interfaces with ARP configuration and state."; 348 container arp { 349 description 350 "Address Resolution Protocol (ARP) related configuration 351 and state"; 352 leaf expiry-time { 353 type uint32 { 354 range "30..86400"; 355 } 356 units "seconds"; 357 description 358 "Aging time of a received dynamic ARP entry before it is 359 removed from the cache."; 360 } 361 leaf dynamic-learning { 362 type boolean; 363 description 364 "Controls whether dynamic ARP learning is enabled on the 365 interface. If not configured, it defaults to the behavior 366 specified in the per-device /arp/dynamic-learning leaf. 368 true - dynamic learning is enabled 369 false - dynamic learning is disabled"; 370 } 371 container proxy-arp { 372 description 373 "Configuration parameters for proxy ARP"; 374 leaf mode { 375 type enumeration { 376 enum disabled { 377 description 378 "The system only responds to ARP requests that 379 specify a target address configured on the local 380 interface."; 381 } 382 enum remote-only { 383 description 384 "The system responds to ARP requests only when the 385 sender and target IP addresses are in different 386 subnets."; 387 } 388 enum all { 389 description 390 "The system responds to ARP requests where the sender 391 and target IP addresses are in different subnets, as 392 well as those where they are in the same subnet."; 393 } 394 } 395 default "disabled"; 396 description 397 "When set to a value other than 'disable', the local 398 system should respond to ARP requests that are for 399 target addresses other than those that are configured on 400 the local subinterface using its own MAC address as the 401 target hardware address. If the 'remote-only' value is 402 specified, replies are only sent when the target address 403 falls outside the locally configured subnets on the 404 interface, whereas with the 'all' value, all requests, 405 regardless of their target address are replied to."; 406 reference 407 "RFC1027: Using ARP to Implement Transparent Subnet 408 Gateways"; 409 } 410 } 411 container gratuitous-arp { 412 description "Configure gratuitous ARP."; 413 reference "RFC5227: IPv4 Address Conflict Detection"; 414 leaf enable { 415 type boolean; 416 description 417 "Enable or disable sending gratuitous ARP packet on the 418 interface. The default behaviour is device specific"; 419 } 420 leaf interval { 421 type uint32 { 422 range "1..86400"; 423 } 424 units "seconds"; 425 description 426 "The interval, in seconds, between sending gratuitous ARP 427 packet on the interface."; 428 } 429 } 430 container statistics { 431 config false; 432 description 433 "ARP per-interface packet statistics 435 For all ARP counters, discontinuities in the value can 436 occur at re-initialization of the management system and at 437 other times as indicated by the value of 438 'discontinuity-time'."; 440 leaf discontinuity-time { 441 type yang:date-and-time; 442 description 443 "The time on the most recent occasion at which any one or 444 more of this interface's ARP counters suffered a 445 discontinuity. If no such discontinuities have occurred 446 since the last re-initialization of the local management 447 subsystem, then this node contains the time the local 448 management subsystem re-initialized itself."; 449 } 451 leaf in-requests-pkts { 452 type yang:counter32; 453 description 454 "The number of ARP request packets received on this 455 interface."; 456 } 458 leaf in-replies-pkts { 459 type yang:counter32; 460 description 461 "The number of ARP reply packets received on this 462 interface."; 463 } 464 leaf in-gratuitous-pkts { 465 type yang:counter32; 466 description 467 "The number of gratuitous ARP packets received on this 468 interface."; 469 } 470 leaf out-requests-pkts { 471 type yang:counter32; 472 description 473 "The number of ARP request packets sent on this interface."; 474 } 475 leaf out-replies-pkts { 476 type yang:counter32; 477 description 478 "The number of ARP reply packets sent on this interface."; 480 } 481 leaf out-gratuitous-pkts { 482 type yang:counter32; 483 description 484 "The number of gratuitous ARP packets sent on this 485 interface."; 486 } 487 } 488 } 489 } 491 augment "/if:interfaces/if:interface/ip:ipv4/ip:neighbor" { 492 description 493 "Augment IPv4 neighbor list with ARP expiry time."; 494 leaf remaining-expiry-time { 495 type uint32; 496 units "seconds"; 497 config false; 498 description 499 "The number of seconds until the dynamic ARP entry expires and is 500 removed from the ARP cache"; 501 } 502 } 503 } 505 5. Data Model Examples 507 This section presents a simple example of configuring static ARP 508 entries and dynamic learning, based on the YANG modules specified in 509 Section 4. 511 5.1. Static ARP Entries 513 Requirement: Enable static ARP entry configuration on interface 514 (defined in [RFC8344] ). 516 517 518 519 520 192.0.2.1 521 00e0-fc01-0000 522 static 523 524 525 527 5.2. ARP Dynamic Learning 529 Requirement: Disable ARP dynamic learning configuration. 531 532 533 false 534 535 536 537 eth0 538 539 1200 540 false 541 542 remote-only 543 544 545 true 546 60 547 548 549 550 552 6. IANA Considerations 554 This document registers a URI in the IETF XML registry [RFC3688]. 555 Following the format in [RFC3688], the following registration is 556 requested to be made: 558 URI: urn:ietf:params:xml:ns:yang:ietf-arp Registrant Contact: 559 The IESG. XML: N/A, the requested URI is an XML namespace. 561 This document registers a YANG module in the YANG Module Names 562 registry [RFC6020]. 564 Name: ietf-arp Namespace: urn:ietf:params:xml:ns:yang: 565 ietf-arp Prefix: arp Reference: RFC XXXX 567 7. Security Considerations 569 The YANG module specified in this document defines a schema for data 570 that is designed to be accessed via network management protocols such 571 as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF 572 layer is the secure transport layer, and the mandatory-to-implement 573 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 574 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 575 transport is TLS [RFC8446]. 577 The NETCONF access control model [RFC8341] provides the means to 578 restrict access for particular NETCONF or RESTCONF users to a 579 preconfigured subset of all available NETCONF or RESTCONF protocol 580 operations and content.. 582 There are a number of data nodes defined in this YANG module that are 583 writable/creatable/deletable (i.e., config true, which is the 584 default). These data nodes may be considered sensitive or vulnerable 585 in some network environments. Write operations (e.g., edit-config) 586 to these data nodes without proper protection can have a negative 587 effect on network operations.These are the subtrees and data nodes 588 and their sensitivity/vulnerability: 590 arp/dynamic-learning: This leaf is used to enable ARP dynamic 591 learning on all interfaces.ARP dynamic learning could allow an 592 attacker to inject spoofed traffic into the network, e.g. denial- 593 of- service attack. 595 interface/ipv4/arp/proxy:These leaves are used to enable ARP proxy 596 on interface. They could allow traffic to be mis-configured 597 (denial-of- service attack). 599 interface/ipv4/arp/gratuitous-arp:This leaf is used to enable 600 sending gratuitous ARP packet on an interface.This configuration 601 could allow an attacker to inject spoofed traffic into the 602 network, e.g. man-in-the-middle attack. 604 8. Acknowledgments 606 The authors wish to thank Alex Campbell and Reshad Rahman, Qin Wu, 607 Tom Petch, many others for their helpful comments. 609 9. References 611 9.1. Normative References 613 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 614 Converting Network Protocol Addresses to 48.bit Ethernet 615 Address for Transmission on Ethernet Hardware", STD 37, 616 RFC 826, DOI 10.17487/RFC0826, November 1982, 617 . 619 [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to 620 implement transparent subnet gateways", RFC 1027, 621 DOI 10.17487/RFC1027, October 1987, 622 . 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, 626 DOI 10.17487/RFC2119, March 1997, 627 . 629 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 630 DOI 10.17487/RFC3688, January 2004, 631 . 633 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 634 DOI 10.17487/RFC5227, July 2008, 635 . 637 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 638 the Network Configuration Protocol (NETCONF)", RFC 6020, 639 DOI 10.17487/RFC6020, October 2010, 640 . 642 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 643 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 644 . 646 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 647 RFC 6991, DOI 10.17487/RFC6991, July 2013, 648 . 650 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 651 RFC 7950, DOI 10.17487/RFC7950, August 2016, 652 . 654 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 655 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 656 May 2017, . 658 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 659 and R. Wilton, "Network Management Datastore Architecture 660 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 661 . 663 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 664 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 665 . 667 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 668 RFC 8344, DOI 10.17487/RFC8344, March 2018, 669 . 671 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 672 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 673 . 675 9.2. Informative References 677 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 678 Version 3 for IPv4 and IPv6", RFC 5798, 679 DOI 10.17487/RFC5798, March 2010, 680 . 682 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 683 and A. Bierman, Ed., "Network Configuration Protocol 684 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 685 . 687 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 688 Narten, "An Architecture for Data-Center Network 689 Virtualization over Layer 3 (NVO3)", RFC 8014, 690 DOI 10.17487/RFC8014, December 2016, 691 . 693 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 694 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 695 . 697 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 698 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 699 . 701 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 702 Access Control Model", STD 91, RFC 8341, 703 DOI 10.17487/RFC8341, March 2018, 704 . 706 Authors' Addresses 708 Feng Zheng 709 Huawei 710 101 Software Avenue, Yuhua District 711 Nanjing, Jiangsu 210012 712 China 714 Email: habby.zheng@huawei.com 715 Bo Wu 716 Huawei 718 Email: lana.wubo@huawei.com 720 Robert Wilton 721 Cisco Systems 723 Email: rwilton@cisco.com 725 Xiaojian Ding 727 Email: wjswsl@163.com