idnits 2.17.1 draft-ietf-netconf-netconf-client-server-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 February 2021) is 1143 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-20 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-22 == Outdated reference: A later version (-24) exists of draft-ietf-netconf-tcp-client-server-08 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-22 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-05 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-21 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-21 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-13 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track 10 February 2021 5 Expires: 14 August 2021 7 NETCONF Client and Server Models 8 draft-ietf-netconf-netconf-client-server-22 10 Abstract 12 This document defines two YANG modules, one module to configure a 13 NETCONF client and the other module to configure a NETCONF server. 14 Both modules support both the SSH and TLS transport protocols, and 15 support both standard NETCONF and NETCONF Call Home connections. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains placeholder values that need to be replaced with 20 finalized values at the time of publication. This note summarizes 21 all of the substitutions that are needed. No other RFC Editor 22 instructions are specified elsewhere in this document. 24 Artwork in this document contains shorthand references to drafts in 25 progress. Please apply the following replacements (note: not all may 26 be present): 28 * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- 29 types 31 * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- 32 anchors 34 * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore 36 * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- 37 client-server 39 * "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- 40 client-server 42 * "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- 43 client-server 45 * "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- 46 client-server 48 * "HHHH" --> the assigned RFC value for this draft 49 Artwork in this document contains placeholder values for the date of 50 publication of this draft. Please apply the following replacement: 52 * "2021-02-10" --> the publication date of this draft 54 The following Appendix section is to be removed prior to publication: 56 * Appendix A. Change Log 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at https://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on 14 August 2021. 75 Copyright Notice 77 Copyright (c) 2021 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 82 license-info) in effect on the date of publication of this document. 83 Please review these documents carefully, as they describe your rights 84 and restrictions with respect to this document. Code Components 85 extracted from this document must include Simplified BSD License text 86 as described in Section 4.e of the Trust Legal Provisions and are 87 provided without warranty as described in the Simplified BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 92 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 4 93 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 94 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 95 2. The "ietf-netconf-client" Module . . . . . . . . . . . . . . 5 96 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 97 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 10 98 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 99 3. The "ietf-netconf-server" Module . . . . . . . . . . . . . . 25 100 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 25 101 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 30 102 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 36 103 4. Security Considerations . . . . . . . . . . . . . . . . . . . 49 104 4.1. The "ietf-netconf-client" YANG Module . . . . . . . . . . 49 105 4.2. The "ietf-netconf-server" YANG Module . . . . . . . . . . 49 106 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 107 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 50 108 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 50 109 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 110 6.1. Normative References . . . . . . . . . . . . . . . . . . 50 111 6.2. Informative References . . . . . . . . . . . . . . . . . 52 112 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 53 113 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 53 114 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 53 115 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 54 116 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 54 117 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 54 118 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 54 119 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 54 120 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 55 121 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 55 122 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 55 123 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 55 124 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 55 125 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 56 126 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 56 127 A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 56 128 A.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 56 129 A.17. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 56 130 A.18. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 57 131 A.19. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 57 132 A.20. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 57 133 A.21. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 57 134 A.22. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 57 135 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58 136 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58 138 1. Introduction 140 This document defines two YANG [RFC7950] modules, one module to 141 configure a NETCONF [RFC6241] client and the other module to 142 configure a NETCONF server. Both modules support both NETCONF over 143 SSH [RFC6242] and NETCONF over TLS [RFC7589] and NETCONF Call Home 144 connections [RFC8071]. 146 1.1. Relation to other RFCs 148 This document presents one or more YANG modules [RFC7950] that are 149 part of a collection of RFCs that work together to, ultimately, 150 enable the configuration of the clients and servers of both the 151 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 153 The modules have been defined in a modular fashion to enable their 154 use by other efforts, some of which are known to be in progress at 155 the time of this writing, with many more expected to be defined in 156 time. 158 The normative dependency relationship between the various RFCs in the 159 collection is presented in the below diagram. The labels in the 160 diagram represent the primary purpose provided by each RFC. 161 Hyperlinks to each RFC are provided below the diagram. 163 crypto-types 164 ^ ^ 165 / \ 166 / \ 167 truststore keystore 168 ^ ^ ^ ^ 169 | +---------+ | | 170 | | | | 171 | +------------+ | 172 tcp-client-server | / | | 173 ^ ^ ssh-client-server | | 174 | | ^ tls-client-server 175 | | | ^ ^ http-client-server 176 | | | | | ^ 177 | | | +-----+ +---------+ | 178 | | | | | | 179 | +-----------|--------|--------------+ | | 180 | | | | | | 181 +-----------+ | | | | | 182 | | | | | | 183 | | | | | | 184 netconf-client-server restconf-client-server 186 +=======================+===========================================+ 187 |Label in Diagram | Originating RFC | 188 +=======================+===========================================+ 189 |crypto-types | [I-D.ietf-netconf-crypto-types] | 190 +-----------------------+-------------------------------------------+ 191 |truststore | [I-D.ietf-netconf-trust-anchors] | 192 +-----------------------+-------------------------------------------+ 193 |keystore | [I-D.ietf-netconf-keystore] | 194 +-----------------------+-------------------------------------------+ 195 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 196 +-----------------------+-------------------------------------------+ 197 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 198 +-----------------------+-------------------------------------------+ 199 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 200 +-----------------------+-------------------------------------------+ 201 |http-client-server | [I-D.ietf-netconf-http-client-server] | 202 +-----------------------+-------------------------------------------+ 203 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 204 +-----------------------+-------------------------------------------+ 205 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 206 +-----------------------+-------------------------------------------+ 208 Table 1: Label to RFC Mapping 210 1.2. Specification Language 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 214 "OPTIONAL" in this document are to be interpreted as described in BCP 215 14 [RFC2119] [RFC8174] when, and only when, they appear in all 216 capitals, as shown here. 218 1.3. Adherence to the NMDA 220 This document in compliant with the Network Management Datastore 221 Architecture (NMDA) [RFC8342]. For instance, as described in 222 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore], 223 trust anchors and keys installed during manufacturing are expected to 224 appear in . 226 2. The "ietf-netconf-client" Module 228 The NETCONF client model presented in this section supports both 229 clients initiating connections to servers, as well as clients 230 listening for connections from servers calling home, using either the 231 SSH and TLS transport protocols. 233 YANG feature statements are used to enable implementations to 234 advertise which potentially uncommon parts of the model the NETCONF 235 client supports. 237 2.1. Data Model Overview 239 This section provides an overview of the "ietf-netconf-client" module 240 in terms of its features and groupings. 242 2.1.1. Features 244 The following diagram lists all the "feature" statements defined in 245 the "ietf-netconf-client" module: 247 Features: 248 +-- ssh-initiate 249 +-- tls-initiate 250 +-- ssh-listen 251 +-- tls-listen 253 | The diagram above uses syntax that is similar to but not 254 | defined in [RFC8340]. 256 2.1.2. Groupings 258 The "ietf-netconf-client" module defines the following "grouping" 259 statements: 261 * netconf-client-grouping 262 * netconf-client-initiate-stack-grouping 263 * netconf-client-listen-stack-grouping 264 * netconf-client-app-grouping 266 Each of these groupings are presented in the following subsections. 268 2.1.2.1. The "netconf-client-grouping" Grouping 270 The following tree diagram [RFC8340] illustrates the "netconf-client- 271 grouping" grouping: 273 grouping netconf-client-grouping ---> 275 Comments: 277 * This grouping does not define any nodes, but is maintained so that 278 downstream modules can augment nodes into it if needed. 280 * The "netconf-client-grouping" defines, if it can be called that, 281 the configuration for just "NETCONF" part of a protocol stack. It 282 does not, for instance, define any configuration for the "TCP", 283 "SSH" or "TLS" protocol layers (for that, see Section 2.1.2.2 and 284 Section 2.1.2.3). 286 2.1.2.2. The "netconf-client-initiate-stack-grouping" Grouping 288 The following tree diagram [RFC8340] illustrates the "netconf-client- 289 initiate-stack-grouping" grouping: 291 grouping netconf-client-initiate-stack-grouping 292 +-- (transport) 293 +--:(ssh) {ssh-initiate}? 294 | +-- ssh 295 | +-- tcp-client-parameters 296 | | +---u tcpc:tcp-client-grouping 297 | +-- ssh-client-parameters 298 | | +---u sshc:ssh-client-grouping 299 | +-- netconf-client-parameters 300 | +--u ncc:netconf-client-grouping 301 +--:(tls) {tls-initiate}? 302 +-- tls 303 +-- tcp-client-parameters 304 | +---u tcpc:tcp-client-grouping 305 +-- tls-client-parameters 306 | +---u tlsc:tls-client-grouping 307 +-- netconf-client-parameters 308 +---u ncc:netconf-client-grouping 310 Comments: 312 * The "netconf-client-initiate-stack-grouping" defines the 313 configuration for a full NETCONF protocol stack, for NETCONF 314 clients that initiate connections to NETCONF servers, as opposed 315 to receiving call-home [RFC8071] connections. 317 * The "transport" choice node enables both the SSH and TLS 318 transports to be configured, with each option enabled by a 319 "feature" statement. 321 * For the referenced grouping statement(s): 323 - The "tcp-client-grouping" grouping is discussed in 324 Section 3.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 325 - The "ssh-client-grouping" grouping is discussed in 326 Section 3.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 328 - The "tls-client-grouping" grouping is discussed in 329 Section 3.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 330 - The "netconf-client-grouping" grouping is discussed in 331 Section 2.1.2.1 in this document. 333 2.1.2.3. The "netconf-client-listen-stack-grouping" Grouping 335 The following tree diagram [RFC8340] illustrates the "netconf-client- 336 listen-stack-grouping" grouping: 338 grouping netconf-client-listen-stack-grouping 339 +-- (transport) 340 +--:(ssh) {ssh-listen}? 341 | +-- ssh 342 | +-- tcp-server-parameters 343 | | +---u tcps:tcp-server-grouping 344 | +-- ssh-client-parameters 345 | | +---u sshc:ssh-client-grouping 346 | +-- netconf-client-parameters 347 | +--u ncc:netconf-client-grouping 348 +--:(tls) {tls-listen}? 349 +-- tls 350 +-- tcp-server-parameters 351 | +---u tcps:tcp-server-grouping 352 +-- tls-client-parameters 353 | +---u tlsc:tls-client-grouping 354 +-- netconf-client-parameters 355 +---u ncc:netconf-client-grouping 357 Comments: 359 * The "netconf-client-listen-stack-grouping" defines the 360 configuration for a full NETCONF protocol stack, for NETCONF 361 clients that receive call-home [RFC8071] connections from NETCONF 362 servers. 364 * The "transport" choice node enables both the SSH and TLS 365 transports to be configured, with each option enabled by a 366 "feature" statement. 368 * For the referenced grouping statement(s): 370 - The "tcp-server-grouping" grouping is discussed in 371 Section 4.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 372 - The "ssh-client-grouping" grouping is discussed in 373 Section 3.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 374 - The "tls-client-grouping" grouping is discussed in 375 Section 3.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 377 - The "netconf-client-grouping" grouping is discussed in 378 Section 2.1.2.1 in this document. 380 2.1.2.4. The "netconf-client-app-grouping" Grouping 382 The following tree diagram [RFC8340] illustrates the "netconf-client- 383 app-grouping" grouping: 385 grouping netconf-client-app-grouping 386 +-- initiate! {ssh-initiate or tls-initiate}? 387 | +-- netconf-server* [name] 388 | +-- name? string 389 | +-- endpoints 390 | | +-- endpoint* [name] 391 | | +-- name? string 392 | | +---u netconf-client-initiate-stack-grouping 393 | +-- connection-type 394 | | +-- (connection-type) 395 | | +--:(persistent-connection) 396 | | | +-- persistent! 397 | | +--:(periodic-connection) 398 | | +-- periodic! 399 | | +-- period? uint16 400 | | +-- anchor-time? yang:date-and-time 401 | | +-- idle-timeout? uint16 402 | +-- reconnect-strategy 403 | +-- start-with? enumeration 404 | +-- max-attempts? uint8 405 +-- listen! {ssh-listen or tls-listen}? 406 +-- idle-timeout? uint16 407 +-- endpoint* [name] 408 +-- name? string 409 +---u netconf-client-listen-stack-grouping 411 Comments: 413 * The "netconf-client-app-grouping" defines the configuration for a 414 NETCONF client that supports both initiating connections to 415 NETCONF servers as well as receiving call-home connections from 416 NETCONF servers. 418 * Both the "initiate" and "listen" subtrees must be enabled by 419 "feature" statements. 421 * For the referenced grouping statement(s): 423 - The "netconf-client-initiate-stack-grouping" grouping is 424 discussed in Section 2.1.2.2 in this document. 426 - The "netconf-client-listen-stack-grouping" grouping is 427 discussed in Section 2.1.2.3 in this document. 429 2.1.3. Protocol-accessible Nodes 431 The following tree diagram [RFC8340] lists all the protocol- 432 accessible nodes defined in the "ietf-netconf-client" module: 434 module: ietf-netconf-client 435 +--rw netconf-client 436 +---u netconf-client-app-grouping 438 Comments: 440 * Protocol-accessible nodes are those nodes that are accessible when 441 the module is "implemented", as described in Section 5.6.5 of 442 [RFC7950]. 444 * For the "ietf-netconf-client" module, the protocol-accessible 445 nodes are an instance of the "netconf-client-app-grouping" 446 discussed in Section 2.1.2.4 grouping. 448 * The reason for why "netconf-client-app-grouping" exists separate 449 from the protocol-accessible nodes definition is so as to enable 450 instances of netconf-client-app-grouping to be instantiated in 451 other locations, as may be needed or desired by some modules. 453 2.2. Example Usage 455 The following example illustrates configuring a NETCONF client to 456 initiate connections, using both the SSH and TLS transport protocols, 457 as well as to listen for call-home connections, again using both the 458 SSH and TLS transport protocols. 460 This example is consistent with the examples presented in Section 2.2 461 of [I-D.ietf-netconf-trust-anchors] and Section 2.2 of 462 [I-D.ietf-netconf-keystore]. 464 =============== NOTE: '\' line wrapping per RFC 8792 ================ 466 470 471 472 473 corp-fw1 474 475 476 corp-fw1.example.com 477 478 479 corp-fw1.example.com 480 481 15 482 3 483 30 484 485 486 487 488 foobar 489 490 ssh-rsa-key 492 493 494 495 496 trusted-server-ca-certs 498 499 500 trusted-server-ee-certs 502 503 504 505 30 506 3 507 508 509 510 511 512 513 514 515 corp-fw2.example.com 516 517 518 corp-fw2.example.com 519 520 15 521 3 522 30 523 524 525 526 527 528 529 rsa-asymmetric-key 531 ex-rsa-cert 532 533 534 535 536 537 trusted-server-ca-certs 539 540 541 trusted-server-ee-certs 543 544 545 546 547 30 548 3 549 550 551 552 553 554 555 556 557 558 559 560 561 562 last-connected 563 564 565 567 568 569 570 Intranet-facing SSH listener 571 572 573 192.0.2.7 574 575 576 577 foobar 578 579 ssh-rsa-key 580 581 582 583 584 trusted-server-ca-certs 586 587 588 trusted-server-ee-certs 590 591 592 trusted-ssh-public-keys 594 595 596 597 598 599 600 601 602 603 Intranet-facing TLS listener 604 605 606 192.0.2.7 607 608 609 610 611 612 rsa-asymmetric-key 613 ex-rsa-cert 614 615 616 617 618 619 trusted-server-ca-certs 621 622 623 trusted-server-ee-certs 625 626 627 628 629 630 631 632 633 634 635 636 637 639 2.3. YANG Module 641 This YANG module has normative references to [RFC6242], [RFC6991], 642 [RFC7589], [RFC8071], [I-D.ietf-netconf-tcp-client-server], 643 [I-D.ietf-netconf-ssh-client-server], and 644 [I-D.ietf-netconf-tls-client-server]. 646 file "ietf-netconf-client@2021-02-10.yang" 648 module ietf-netconf-client { 649 yang-version 1.1; 650 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-client"; 651 prefix ncc; 653 import ietf-yang-types { 654 prefix yang; 655 reference 656 "RFC 6991: Common YANG Data Types"; 657 } 659 import ietf-tcp-client { 660 prefix tcpc; 661 reference 662 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 663 } 665 import ietf-tcp-server { 666 prefix tcps; 667 reference 668 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 669 } 671 import ietf-ssh-client { 672 prefix sshc; 673 revision-date 2021-02-10; // stable grouping definitions 674 reference 675 "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers"; 676 } 678 import ietf-tls-client { 679 prefix tlsc; 680 revision-date 2021-02-10; // stable grouping definitions 681 reference 682 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers"; 683 } 685 organization 686 "IETF NETCONF (Network Configuration) Working Group"; 688 contact 689 "WG Web: 690 WG List: 691 Author: Kent Watsen 692 Author: Gary Wu "; 694 description 695 "This module contains a collection of YANG definitions 696 for configuring NETCONF clients. 698 Copyright (c) 2020 IETF Trust and the persons identified 699 as authors of the code. All rights reserved. 701 Redistribution and use in source and binary forms, with 702 or without modification, is permitted pursuant to, and 703 subject to the license terms contained in, the Simplified 704 BSD License set forth in Section 4.c of the IETF Trust's 705 Legal Provisions Relating to IETF Documents 706 (https://trustee.ietf.org/license-info). 708 This version of this YANG module is part of RFC HHHH 709 (https://www.rfc-editor.org/info/rfcHHHH); see the RFC 710 itself for full legal notices.; 712 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 713 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 714 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 715 are to be interpreted as described in BCP 14 (RFC 2119) 716 (RFC 8174) when, and only when, they appear in all 717 capitals, as shown here."; 719 revision 2021-02-10 { 720 description 721 "Initial version"; 722 reference 723 "RFC HHHH: NETCONF Client and Server Models"; 724 } 726 // Features 728 feature ssh-initiate { 729 description 730 "The 'ssh-initiate' feature indicates that the NETCONF client 731 supports initiating SSH connections to NETCONF servers."; 732 reference 733 "RFC 6242: 734 Using the NETCONF Protocol over Secure Shell (SSH)"; 735 } 737 feature tls-initiate { 738 description 739 "The 'tls-initiate' feature indicates that the NETCONF client 740 supports initiating TLS connections to NETCONF servers."; 741 reference 742 "RFC 7589: Using the NETCONF Protocol over Transport 743 Layer Security (TLS) with Mutual X.509 Authentication"; 744 } 746 feature ssh-listen { 747 description 748 "The 'ssh-listen' feature indicates that the NETCONF client 749 supports opening a port to listen for incoming NETCONF 750 server call-home SSH connections."; 751 reference 752 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 753 } 755 feature tls-listen { 756 description 757 "The 'tls-listen' feature indicates that the NETCONF client 758 supports opening a port to listen for incoming NETCONF 759 server call-home TLS connections."; 760 reference 761 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 763 } 765 // Groupings 767 grouping netconf-client-grouping { 768 description 769 "A reusable grouping for configuring a NETCONF client 770 without any consideration for how underlying transport 771 sessions are established. 773 This grouping currently doesn't define any nodes."; 774 } 776 grouping netconf-client-initiate-stack-grouping { 777 description 778 "A reusable grouping for configuring a NETCONF client 779 'initiate' protocol stack for a single connection."; 780 choice transport { 781 mandatory true; 782 description 783 "Selects between available transports."; 784 case ssh { 785 if-feature "ssh-initiate"; 786 container ssh { 787 description 788 "Specifies IP and SSH specific configuration 789 for the connection."; 790 container tcp-client-parameters { 791 description 792 "A wrapper around the TCP client parameters 793 to avoid name collisions."; 794 uses tcpc:tcp-client-grouping { 795 refine "remote-port" { 796 default "830"; 797 description 798 "The NETCONF client will attempt to connect 799 to the IANA-assigned well-known port value 800 for 'netconf-ssh' (830) if no value is 801 specified."; 802 } 803 } 804 } 805 container ssh-client-parameters { 806 description 807 "A wrapper around the SSH client parameters to 808 avoid name collisions."; 809 uses sshc:ssh-client-grouping; 810 } 811 container netconf-client-parameters { 812 description 813 "A wrapper around the NETCONF client parameters 814 to avoid name collisions."; 815 uses ncc:netconf-client-grouping; 816 } 817 } 818 } 819 case tls { 820 if-feature "tls-initiate"; 821 container tls { 822 description 823 "Specifies IP and TLS specific configuration 824 for the connection."; 825 container tcp-client-parameters { 826 description 827 "A wrapper around the TCP client parameters 828 to avoid name collisions."; 829 uses tcpc:tcp-client-grouping { 830 refine "remote-port" { 831 default "6513"; 832 description 833 "The NETCONF client will attempt to connect 834 to the IANA-assigned well-known port value 835 for 'netconf-tls' (6513) if no value is 836 specified."; 837 } 838 } 839 } 840 container tls-client-parameters { 841 must "client-identity" { 842 description 843 "NETCONF/TLS clients MUST pass some 844 authentication credentials."; 845 } 846 description 847 "A wrapper around the TLS client parameters 848 to avoid name collisions."; 849 uses tlsc:tls-client-grouping; 850 } 851 container netconf-client-parameters { 852 description 853 "A wrapper around the NETCONF client parameters 854 to avoid name collisions."; 855 uses ncc:netconf-client-grouping; 856 } 857 } 858 } 860 } 861 } // netconf-client-initiate-stack-grouping 863 grouping netconf-client-listen-stack-grouping { 864 description 865 "A reusable grouping for configuring a NETCONF client 866 'listen' protocol stack for a single connection. The 867 'listen' stack supports call home connections, as 868 described in RFC 8071"; 869 reference 870 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 871 choice transport { 872 mandatory true; 873 description 874 "Selects between available transports."; 875 case ssh { 876 if-feature "ssh-listen"; 877 container ssh { 878 description 879 "SSH-specific listening configuration for inbound 880 connections."; 881 container tcp-server-parameters { 882 description 883 "A wrapper around the TCP server parameters 884 to avoid name collisions."; 885 uses tcps:tcp-server-grouping { 886 refine "local-port" { 887 default "4334"; 888 description 889 "The NETCONF client will listen on the IANA- 890 assigned well-known port for 'netconf-ch-ssh' 891 (4334) if no value is specified."; 892 } 893 } 894 } 895 container ssh-client-parameters { 896 description 897 "A wrapper around the SSH client parameters 898 to avoid name collisions."; 899 uses sshc:ssh-client-grouping; 900 } 901 container netconf-client-parameters { 902 description 903 "A wrapper around the NETCONF client parameters 904 to avoid name collisions."; 905 uses ncc:netconf-client-grouping; 906 } 907 } 909 } 910 case tls { 911 if-feature "tls-listen"; 912 container tls { 913 description 914 "TLS-specific listening configuration for inbound 915 connections."; 916 container tcp-server-parameters { 917 description 918 "A wrapper around the TCP server parameters 919 to avoid name collisions."; 920 uses tcps:tcp-server-grouping { 921 refine "local-port" { 922 default "4334"; 923 description 924 "The NETCONF client will listen on the IANA- 925 assigned well-known port for 'netconf-ch-ssh' 926 (4334) if no value is specified."; 927 } 928 } 929 } 930 container tls-client-parameters { 931 must "client-identity" { 932 description 933 "NETCONF/TLS clients MUST pass some 934 authentication credentials."; 935 } 936 description 937 "A wrapper around the TLS client parameters 938 to avoid name collisions."; 939 uses tlsc:tls-client-grouping; 940 } 941 container netconf-client-parameters { 942 description 943 "A wrapper around the NETCONF client parameters 944 to avoid name collisions."; 945 uses ncc:netconf-client-grouping; 946 } 947 } 948 } 949 } 950 } // netconf-client-listen-stack-grouping 952 grouping netconf-client-app-grouping { 953 description 954 "A reusable grouping for configuring a NETCONF client 955 application that supports both 'initiate' and 'listen' 956 protocol stacks for a multiplicity of connections."; 958 container initiate { 959 if-feature "ssh-initiate or tls-initiate"; 960 presence "Enables client to initiate TCP connections"; 961 description 962 "Configures client initiating underlying TCP connections."; 963 list netconf-server { 964 key "name"; 965 min-elements 1; 966 description 967 "List of NETCONF servers the NETCONF client is to 968 maintain simultaneous connections with."; 969 leaf name { 970 type string; 971 description 972 "An arbitrary name for the NETCONF server."; 973 } 974 container endpoints { 975 description 976 "Container for the list of endpoints."; 977 list endpoint { 978 key "name"; 979 min-elements 1; 980 ordered-by user; 981 description 982 "A user-ordered list of endpoints that the NETCONF 983 client will attempt to connect to in the specified 984 sequence. Defining more than one enables 985 high-availability."; 986 leaf name { 987 type string; 988 description 989 "An arbitrary name for the endpoint."; 990 } 991 uses netconf-client-initiate-stack-grouping; 992 } // list endpoint 993 } // container endpoints 995 container connection-type { 996 description 997 "Indicates the NETCONF client's preference for how the 998 NETCONF connection is maintained."; 999 choice connection-type { 1000 mandatory true; 1001 description 1002 "Selects between available connection types."; 1003 case persistent-connection { 1004 container persistent { 1005 presence "Indicates that a persistent connection is 1006 to be maintained."; 1007 description 1008 "Maintain a persistent connection to the NETCONF 1009 server. If the connection goes down, immediately 1010 start trying to reconnect to the NETCONF server, 1011 using the reconnection strategy. 1013 This connection type minimizes any NETCONF server 1014 to NETCONF client data-transfer delay, albeit at 1015 the expense of holding resources longer."; 1016 } 1017 } 1018 case periodic-connection { 1019 container periodic { 1020 presence "Indicates that a periodic connection is 1021 to be maintained."; 1022 description 1023 "Periodically connect to the NETCONF server. 1025 This connection type increases resource 1026 utilization, albeit with increased delay in 1027 NETCONF server to NETCONF client interactions. 1029 The NETCONF client should close the underlying 1030 TCP connection upon completing planned activities. 1032 In the case that the previous connection is still 1033 active, establishing a new connection is NOT 1034 RECOMMENDED."; 1035 leaf period { 1036 type uint16; 1037 units "minutes"; 1038 default "60"; 1039 description 1040 "Duration of time between periodic connections."; 1041 } 1042 leaf anchor-time { 1043 type yang:date-and-time { 1044 // constrained to minute-level granularity 1045 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}' 1046 + '(Z|[\+\-]\d{2}:\d{2})'; 1047 } 1048 description 1049 "Designates a timestamp before or after which a 1050 series of periodic connections are determined. 1051 The periodic connections occur at a whole 1052 multiple interval from the anchor time. For 1053 example, for an anchor time is 15 minutes past 1054 midnight and a period interval of 24 hours, then 1055 a periodic connection will occur 15 minutes past 1056 midnight everyday."; 1057 } 1058 leaf idle-timeout { 1059 type uint16; 1060 units "seconds"; 1061 default 120; // two minutes 1062 description 1063 "Specifies the maximum number of seconds that 1064 a NETCONF session may remain idle. A NETCONF 1065 session will be dropped if it is idle for an 1066 interval longer then this number of seconds. 1067 If set to zero, then the NETCONF client will 1068 never drop a session because it is idle."; 1069 } 1070 } 1071 } 1072 } 1073 } 1074 container reconnect-strategy { 1075 description 1076 "The reconnection strategy directs how a NETCONF client 1077 reconnects to a NETCONF server, after discovering its 1078 connection to the server has dropped, even if due to a 1079 reboot. The NETCONF client starts with the specified 1080 endpoint and tries to connect to it max-attempts times 1081 before trying the next endpoint in the list (round 1082 robin)."; 1083 leaf start-with { 1084 type enumeration { 1085 enum first-listed { 1086 description 1087 "Indicates that reconnections should start with 1088 the first endpoint listed."; 1089 } 1090 enum last-connected { 1091 description 1092 "Indicates that reconnections should start with 1093 the endpoint last connected to. If no previous 1094 connection has ever been established, then the 1095 first endpoint configured is used. NETCONF 1096 clients SHOULD be able to remember the last 1097 endpoint connected to across reboots."; 1098 } 1099 enum random-selection { 1100 description 1101 "Indicates that reconnections should start with 1102 a random endpoint."; 1103 } 1104 } 1105 default "first-listed"; 1106 description 1107 "Specifies which of the NETCONF server's endpoints 1108 the NETCONF client should start with when trying 1109 to connect to the NETCONF server."; 1110 } 1111 leaf max-attempts { 1112 type uint8 { 1113 range "1..max"; 1114 } 1115 default "3"; 1116 description 1117 "Specifies the number times the NETCONF client tries 1118 to connect to a specific endpoint before moving on 1119 to the next endpoint in the list (round robin)."; 1120 } 1121 } 1122 } // netconf-server 1123 } // initiate 1125 container listen { 1126 if-feature "ssh-listen or tls-listen"; 1127 presence "Enables client to accept call-home connections"; 1128 description 1129 "Configures the client to accept call-home TCP connections."; 1130 leaf idle-timeout { 1131 type uint16; 1132 units "seconds"; 1133 default "3600"; // one hour 1134 description 1135 "Specifies the maximum number of seconds that a NETCONF 1136 session may remain idle. A NETCONF session will be 1137 dropped if it is idle for an interval longer than this 1138 number of seconds. If set to zero, then the server 1139 will never drop a session because it is idle. Sessions 1140 that have a notification subscription active are never 1141 dropped."; 1142 } 1143 list endpoint { 1144 key "name"; 1145 min-elements 1; 1146 description 1147 "List of endpoints to listen for NETCONF connections."; 1148 leaf name { 1149 type string; 1150 description 1151 "An arbitrary name for the NETCONF listen endpoint."; 1152 } 1153 uses netconf-client-listen-stack-grouping; 1154 } // endpoint 1155 } // listen 1156 } // netconf-client-app-grouping 1158 // Protocol accessible node, for servers that implement 1159 // this module. 1160 container netconf-client { 1161 uses netconf-client-app-grouping; 1162 description 1163 "Top-level container for NETCONF client configuration."; 1164 } 1165 } 1167 1169 3. The "ietf-netconf-server" Module 1171 The NETCONF server model presented in this section supports both 1172 listening for connections as well as initiating call-home 1173 connections, using either the SSH and TLS transport protocols. 1175 YANG feature statements are used to enable implementations to 1176 advertise which potentially uncommon parts of the model the NETCONF 1177 server supports. 1179 3.1. Data Model Overview 1181 This section provides an overview of the "ietf-netconf-server" module 1182 in terms of its features and groupings. 1184 3.1.1. Features 1186 The following diagram lists all the "feature" statements defined in 1187 the "ietf-netconf-server" module: 1189 Features: 1190 +-- ssh-listen 1191 +-- tls-listen 1192 +-- ssh-call-home 1193 +-- tls-call-home 1195 | The diagram above uses syntax that is similar to but not 1196 | defined in [RFC8340]. 1198 3.1.2. Groupings 1200 The "ietf-netconf-server" module defines the following "grouping" 1201 statements: 1203 * netconf-server-grouping 1204 * netconf-server-listen-stack-grouping 1205 * netconf-server-callhome-stack-grouping 1206 * netconf-server-app-grouping 1208 Each of these groupings are presented in the following subsections. 1210 3.1.2.1. The "netconf-server-grouping" Grouping 1212 The following tree diagram [RFC8340] illustrates the "netconf-server- 1213 grouping" grouping: 1215 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1217 grouping netconf-server-grouping 1218 +-- client-identity-mappings 1219 {(tls-listen or tls-call-home) and (sshcmn:ssh-x509-cert\ 1220 s)}? 1221 +---u x509c2n:cert-to-name 1223 Comments: 1225 * The "netconf-server-grouping" defines the configuration for just 1226 "NETCONF" part of a protocol stack. It does not, for instance, 1227 define any configuration for the "TCP", "SSH" or "TLS" protocol 1228 layers (for that, see Section 3.1.2.2 and Section 3.1.2.3). 1230 * The "client-identity-mappings" node, which must be enabled by 1231 "feature" statements, defines a mapping from certificate fields to 1232 NETCONF user names. 1234 * For the referenced grouping statement(s): 1236 - The "cert-to-name" grouping is discussed in Section 4.1 of 1237 [RFC7407]. 1239 3.1.2.2. The "netconf-server-listen-stack-grouping" Grouping 1241 The following tree diagram [RFC8340] illustrates the "netconf-server- 1242 listen-stack-grouping" grouping: 1244 grouping netconf-server-listen-stack-grouping 1245 +-- (transport) 1246 +--:(ssh) {ssh-listen}? 1247 | +-- ssh 1248 | +-- tcp-server-parameters 1249 | | +---u tcps:tcp-server-grouping 1250 | +-- ssh-server-parameters 1251 | | +---u sshs:ssh-server-grouping 1252 | +-- netconf-server-parameters 1253 | +---u ncs:netconf-server-grouping 1254 +--:(tls) {tls-listen}? 1255 +-- tls 1256 +-- tcp-server-parameters 1257 | +---u tcps:tcp-server-grouping 1258 +-- tls-server-parameters 1259 | +---u tlss:tls-server-grouping 1260 +-- netconf-server-parameters 1261 +---u ncs:netconf-server-grouping 1263 Comments: 1265 * The "netconf-server-listen-stack-grouping" defines the 1266 configuration for a full NETCONF protocol stack for NETCONF 1267 servers that listen for standard connections from NETCONF clients, 1268 as opposed to initiating call-home [RFC8071] connections. 1270 * The "transport" choice node enables both the SSH and TLS 1271 transports to be configured, with each option enabled by a 1272 "feature" statement. 1274 * For the referenced grouping statement(s): 1276 - The "tcp-server-grouping" grouping is discussed in 1277 Section 4.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 1278 - The "ssh-server-grouping" grouping is discussed in 1279 Section 4.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 1280 - The "tls-server-grouping" grouping is discussed in 1281 Section 4.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 1282 - The "netconf-server-grouping" is discussed in Section 3.1.2.1 1283 of this document. 1285 3.1.2.3. The "netconf-server-callhome-stack-grouping" Grouping 1287 The following tree diagram [RFC8340] illustrates the "netconf-server- 1288 callhome-stack-grouping" grouping: 1290 grouping netconf-server-callhome-stack-grouping 1291 +-- (transport) 1292 +--:(ssh) {ssh-call-home}? 1293 | +-- ssh 1294 | +-- tcp-client-parameters 1295 | | +---u tcpc:tcp-client-grouping 1296 | +-- ssh-server-parameters 1297 | | +---u sshs:ssh-server-grouping 1298 | +-- netconf-server-parameters 1299 | +---u ncs:netconf-server-grouping 1300 +--:(tls) {tls-call-home}? 1301 +-- tls 1302 +-- tcp-client-parameters 1303 | +---u tcpc:tcp-client-grouping 1304 +-- tls-server-parameters 1305 | +---u tlss:tls-server-grouping 1306 +-- netconf-server-parameters 1307 +---u ncs:netconf-server-grouping 1309 Comments: 1311 * The "netconf-server-callhome-stack-grouping" defines the 1312 configuration for a full NETCONF protocol stack, for NETCONF 1313 servers that initiate call-home [RFC8071] connections to NETCONF 1314 clients. 1316 * The "transport" choice node enables both the SSH and TLS 1317 transports to be configured, with each option enabled by a 1318 "feature" statement. 1320 * For the referenced grouping statement(s): 1322 - The "tcp-client-grouping" grouping is discussed in 1323 Section 3.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 1324 - The "ssh-server-grouping" grouping is discussed in 1325 Section 4.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 1326 - The "tls-server-grouping" grouping is discussed in 1327 Section 4.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 1328 - The "netconf-server-grouping" is discussed in Section 3.1.2.1 1329 of this document. 1331 3.1.2.4. The "netconf-server-app-grouping" Grouping 1333 The following tree diagram [RFC8340] illustrates the "netconf-server- 1334 app-grouping" grouping: 1336 grouping netconf-server-app-grouping 1337 +-- listen! {ssh-listen or tls-listen}? 1338 | +-- idle-timeout? uint16 1339 | +-- endpoint* [name] 1340 | +-- name? string 1341 | +---u netconf-server-listen-stack-grouping 1342 +-- call-home! {ssh-call-home or tls-call-home}? 1343 +-- netconf-client* [name] 1344 +-- name? string 1345 +-- endpoints 1346 | +-- endpoint* [name] 1347 | +-- name? string 1348 | +---u netconf-server-callhome-stack-grouping 1349 +-- connection-type 1350 | +-- (connection-type) 1351 | +--:(persistent-connection) 1352 | | +-- persistent! 1353 | +--:(periodic-connection) 1354 | +-- periodic! 1355 | +-- period? uint16 1356 | +-- anchor-time? yang:date-and-time 1357 | +-- idle-timeout? uint16 1358 +-- reconnect-strategy 1359 +-- start-with? enumeration 1360 +-- max-attempts? uint8 1362 Comments: 1364 * The "netconf-server-app-grouping" defines the configuration for a 1365 NETCONF server that supports both listening for connections from 1366 NETCONF clients as well as initiatiating call-home connections to 1367 NETCONF clients. 1369 * Both the "listen" and "call-home" subtrees must be enabled by 1370 "feature" statements. 1372 * For the referenced grouping statement(s): 1374 - The "netconf-server-listen-stack-grouping" grouping is 1375 discussed in Section 3.1.2.2 in this document. 1376 - The "netconf-server-callhome-stack-grouping" grouping is 1377 discussed in Section 3.1.2.3 in this document. 1379 3.1.3. Protocol-accessible Nodes 1381 The following tree diagram [RFC8340] lists all the protocol- 1382 accessible nodes defined in the "ietf-netconf-server" module: 1384 module: ietf-netconf-server 1385 +--rw netconf-server 1386 +---u netconf-server-app-grouping 1388 | The diagram above uses syntax that is similar to but not 1389 | defined in [RFC8340]. 1391 Comments: 1393 * Protocol-accessible nodes are those nodes that are accessible when 1394 the module is "implemented", as described in Section 5.6.5 of 1395 [RFC7950]. 1397 * For the "ietf-netconf-server" module, the protocol-accessible 1398 nodes are an instance of the "netconf-server-app-grouping" 1399 discussed in Section 3.1.2.4 grouping. 1401 * The reason for why "netconf-server-app-grouping" exists separate 1402 from the protocol-accessible nodes definition is so as to enable 1403 instances of netconf-server-app-grouping to be instantiated in 1404 other locations, as may be needed or desired by some modules. 1406 3.2. Example Usage 1408 The following example illustrates configuring a NETCONF server to 1409 listen for NETCONF client connections using both the SSH and TLS 1410 transport protocols, as well as configuring call-home to two NETCONF 1411 clients, one using SSH and the other using TLS. 1413 This example is consistent with the examples presented in Section 2.2 1414 of [I-D.ietf-netconf-trust-anchors] and Section 2.2 of 1415 [I-D.ietf-netconf-keystore]. 1417 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1419 1424 1425 1426 1427 netconf/ssh 1428 1429 1430 192.0.2.7 1431 1432 1433 1434 1435 deployment-specific-certificate 1436 1437 ssh-rsa-key 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 netconf/tls 1454 1455 1456 192.0.2.7 1457 1458 1459 1460 1461 1462 rsa-asymmetric-key 1463 ex-rsa-cert 1464 1465 1466 1467 1468 1469 trusted-client-ca-certs 1471 1472 1473 trusted-client-ee-certs 1475 1476 1477 1478 1479 1481 1482 1483 1484 1485 1 1486 11:0A:05:11:00 1487 x509c2n:specified 1488 scooby-doo 1489 1490 1491 2 1492 x509c2n:san-any 1493 1494 1495 1496 1497 1498 1500 1501 1502 1503 config-mgr 1504 1505 1506 east-data-center 1507 1508 1509 east.config-mgr.example.com 1511 1512 15 1513 3 1514 30 1515 1516 1517 1518 1519 1520 deployment-specific-certificate 1521 1522 ssh-rsa-key 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 west-data-center 1540 1541 1542 west.config-mgr.example.com 1544 1545 1546 1547 1548 deployment-specific-certificate 1549 1550 ssh-rsa-key 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 300 1570 60 1571 1572 1573 1574 last-connected 1575 3 1576 1578 1579 1580 data-collector 1581 1582 1583 east-data-center 1584 1585 1586 east.analytics.example.com 1588 1589 15 1590 3 1591 30 1592 1593 1594 1595 1596 1597 1598 rsa-asymmetric-key 1600 ex-rsa-cert 1601 1602 1603 1604 1605 1606 trusted-client-ca-certs 1608 1609 1610 trusted-client-ee-certs 1612 1613 1614 1615 1616 30 1617 3 1618 1619 1620 1621 1622 1623 1624 1 1625 11:0A:05:11:00 1626 x509c2n:specified 1627 scooby-doo 1628 1629 1630 2 1631 x509c2n:san-any 1632 1633 1634 1635 1636 1637 1638 west-data-center 1639 1640 1641 west.analytics.example.com 1643 1644 15 1645 3 1646 30 1647 1648 1649 1650 1651 1652 1653 rsa-asymmetric-key 1655 ex-rsa-cert 1656 1657 1658 1659 1660 1661 trusted-client-ca-certs 1663 1664 1665 trusted-client-ee-certs 1667 1668 1669 1670 1671 30 1672 3 1673 1675 1676 1677 1678 1679 1680 1 1681 11:0A:05:11:00 1682 x509c2n:specified 1683 scooby-doo 1684 1685 1686 2 1687 x509c2n:san-any 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 first-listed 1699 3 1700 1701 1702 1703 1705 3.3. YANG Module 1707 This YANG module has normative references to [RFC6242], [RFC6991], 1708 [RFC7407], [RFC7589], [RFC8071], 1709 [I-D.ietf-netconf-tcp-client-server], 1710 [I-D.ietf-netconf-ssh-client-server], and 1711 [I-D.ietf-netconf-tls-client-server]. 1713 file "ietf-netconf-server@2021-02-10.yang" 1715 module ietf-netconf-server { 1716 yang-version 1.1; 1717 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server"; 1718 prefix ncs; 1720 import ietf-yang-types { 1721 prefix yang; 1722 reference 1723 "RFC 6991: Common YANG Data Types"; 1724 } 1726 import ietf-x509-cert-to-name { 1727 prefix x509c2n; 1728 reference 1729 "RFC 7407: A YANG Data Model for SNMP Configuration"; 1730 } 1732 import ietf-tcp-client { 1733 prefix tcpc; 1734 reference 1735 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1736 } 1738 import ietf-tcp-server { 1739 prefix tcps; 1740 reference 1741 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1742 } 1744 import ietf-ssh-common { 1745 prefix sshcmn; 1746 revision-date 2021-02-10; // stable grouping definitions 1747 reference 1748 "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers"; 1749 } 1751 import ietf-ssh-server { 1752 prefix sshs; 1753 revision-date 2021-02-10; // stable grouping definitions 1754 reference 1755 "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers"; 1756 } 1758 import ietf-tls-server { 1759 prefix tlss; 1760 revision-date 2021-02-10; // stable grouping definitions 1761 reference 1762 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers"; 1763 } 1765 organization 1766 "IETF NETCONF (Network Configuration) Working Group"; 1768 contact 1769 "WG Web: 1770 WG List: 1771 Author: Kent Watsen 1772 Author: Gary Wu 1773 Author: Juergen Schoenwaelder 1774 "; 1776 description 1777 "This module contains a collection of YANG definitions 1778 for configuring NETCONF servers. 1780 Copyright (c) 2020 IETF Trust and the persons identified 1781 as authors of the code. All rights reserved. 1783 Redistribution and use in source and binary forms, with 1784 or without modification, is permitted pursuant to, and 1785 subject to the license terms contained in, the Simplified 1786 BSD License set forth in Section 4.c of the IETF Trust's 1787 Legal Provisions Relating to IETF Documents 1788 (https://trustee.ietf.org/license-info). 1790 This version of this YANG module is part of RFC HHHH 1791 (https://www.rfc-editor.org/info/rfcHHHH); see the RFC 1792 itself for full legal notices.; 1794 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1795 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1796 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1797 are to be interpreted as described in BCP 14 (RFC 2119) 1798 (RFC 8174) when, and only when, they appear in all 1799 capitals, as shown here."; 1801 revision 2021-02-10 { 1802 description 1803 "Initial version"; 1804 reference 1805 "RFC HHHH: NETCONF Client and Server Models"; 1806 } 1808 // Features 1810 feature ssh-listen { 1811 description 1812 "The 'ssh-listen' feature indicates that the NETCONF server 1813 supports opening a port to accept NETCONF over SSH 1814 client connections."; 1815 reference 1816 "RFC 6242: 1817 Using the NETCONF Protocol over Secure Shell (SSH)"; 1818 } 1819 feature tls-listen { 1820 description 1821 "The 'tls-listen' feature indicates that the NETCONF server 1822 supports opening a port to accept NETCONF over TLS 1823 client connections."; 1824 reference 1825 "RFC 7589: Using the NETCONF Protocol over Transport 1826 Layer Security (TLS) with Mutual X.509 1827 Authentication"; 1828 } 1830 feature ssh-call-home { 1831 description 1832 "The 'ssh-call-home' feature indicates that the NETCONF 1833 server supports initiating a NETCONF over SSH call 1834 home connection to NETCONF clients."; 1835 reference 1836 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 1837 } 1839 feature tls-call-home { 1840 description 1841 "The 'tls-call-home' feature indicates that the NETCONF 1842 server supports initiating a NETCONF over TLS call 1843 home connection to NETCONF clients."; 1844 reference 1845 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 1846 } 1848 // Groupings 1850 grouping netconf-server-grouping { 1851 description 1852 "A reusable grouping for configuring a NETCONF server 1853 without any consideration for how underlying transport 1854 sessions are established. 1856 Note that this grouping uses a fairly typical descendent 1857 node name such that a stack of 'uses' statements will 1858 have name conflicts. It is intended that the consuming 1859 data model will resolve the issue by wrapping the 'uses' 1860 statement in a container called, e.g., 1861 'netconf-server-parameters'. This model purposely does 1862 not do this itself so as to provide maximum flexibility 1863 to consuming models."; 1865 container client-identity-mappings { 1866 if-feature 1867 "(tls-listen or tls-call-home) and (sshcmn:ssh-x509-certs)"; 1868 description 1869 "Specifies mappings through which NETCONF client X.509 1870 certificates are used to determine a NETCONF username. 1871 If no matching and valid cert-to-name list entry can be 1872 found, then the NETCONF server MUST close the connection, 1873 and MUST NOT accept NETCONF messages over it."; 1874 reference 1875 "RFC 7407: A YANG Data Model for SNMP Configuration."; 1876 uses x509c2n:cert-to-name { 1877 refine "cert-to-name/fingerprint" { 1878 mandatory false; 1879 description 1880 "A 'fingerprint' value does not need to be specified 1881 when the 'cert-to-name' mapping is independent of 1882 fingerprint matching. A 'cert-to-name' having no 1883 fingerprint value will match any client certificate 1884 and therefore should only be present at the end of 1885 the user-ordered 'cert-to-name' list."; 1886 } 1887 } 1888 } 1889 } 1891 grouping netconf-server-listen-stack-grouping { 1892 description 1893 "A reusable grouping for configuring a NETCONF server 1894 'listen' protocol stack for a single connection."; 1895 choice transport { 1896 mandatory true; 1897 description 1898 "Selects between available transports."; 1899 case ssh { 1900 if-feature "ssh-listen"; 1901 container ssh { 1902 description 1903 "SSH-specific listening configuration for inbound 1904 connections."; 1905 container tcp-server-parameters { 1906 description 1907 "A wrapper around the TCP client parameters 1908 to avoid name collisions."; 1909 uses tcps:tcp-server-grouping { 1910 refine "local-port" { 1911 default "830"; 1912 description 1913 "The NETCONF server will listen on the 1914 IANA-assigned well-known port value 1915 for 'netconf-ssh' (830) if no value 1916 is specified."; 1917 } 1918 } 1919 } 1920 container ssh-server-parameters { 1921 description 1922 "A wrapper around the SSH server parameters 1923 to avoid name collisions."; 1924 uses sshs:ssh-server-grouping; 1925 } 1926 container netconf-server-parameters { 1927 description 1928 "A wrapper around the NETCONF server parameters 1929 to avoid name collisions."; 1930 uses ncs:netconf-server-grouping; 1931 } 1932 } 1933 } 1934 case tls { 1935 if-feature "tls-listen"; 1936 container tls { 1937 description 1938 "TLS-specific listening configuration for inbound 1939 connections."; 1940 container tcp-server-parameters { 1941 description 1942 "A wrapper around the TCP client parameters 1943 to avoid name collisions."; 1944 uses tcps:tcp-server-grouping { 1945 refine "local-port" { 1946 default "6513"; 1947 description 1948 "The NETCONF server will listen on the 1949 IANA-assigned well-known port value 1950 for 'netconf-tls' (6513) if no value 1951 is specified."; 1952 } 1953 } 1954 } 1955 container tls-server-parameters { 1956 description 1957 "A wrapper around the TLS server parameters to 1958 avoid name collisions."; 1959 uses tlss:tls-server-grouping { 1960 refine "client-authentication" { 1961 must 'ca-certs or ee-certs'; 1962 description 1963 "NETCONF/TLS servers MUST validate client 1964 certificates. This configures certificates 1965 at the socket-level (i.e. bags), more 1966 discriminating client-certificate checks 1967 SHOULD be implemented by the application."; 1968 reference 1969 "RFC 7589: 1970 Using the NETCONF Protocol over Transport Layer 1971 Security (TLS) with Mutual X.509 Authentication"; 1972 } 1973 } 1974 } 1975 container netconf-server-parameters { 1976 description 1977 "A wrapper around the NETCONF server parameters 1978 to avoid name collisions."; 1979 uses ncs:netconf-server-grouping; 1980 } 1981 } 1982 } 1983 } 1984 } 1986 grouping netconf-server-callhome-stack-grouping { 1987 description 1988 "A reusable grouping for configuring a NETCONF server 1989 'call-home' protocol stack, for a single connection."; 1990 choice transport { 1991 mandatory true; 1992 description 1993 "Selects between available transports."; 1994 case ssh { 1995 if-feature "ssh-call-home"; 1996 container ssh { 1997 description 1998 "Specifies SSH-specific call-home transport 1999 configuration."; 2000 container tcp-client-parameters { 2001 description 2002 "A wrapper around the TCP client parameters 2003 to avoid name collisions."; 2004 uses tcpc:tcp-client-grouping { 2005 refine "remote-port" { 2006 default "4334"; 2007 description 2008 "The NETCONF server will attempt to connect 2009 to the IANA-assigned well-known port for 2010 'netconf-ch-tls' (4334) if no value is 2011 specified."; 2012 } 2013 } 2014 } 2015 container ssh-server-parameters { 2016 description 2017 "A wrapper around the SSH server parameters 2018 to avoid name collisions."; 2019 uses sshs:ssh-server-grouping; 2020 } 2021 container netconf-server-parameters { 2022 description 2023 "A wrapper around the NETCONF server parameters 2024 to avoid name collisions."; 2025 uses ncs:netconf-server-grouping; 2026 } 2027 } 2028 } 2029 case tls { 2030 if-feature "tls-call-home"; 2031 container tls { 2032 description 2033 "Specifies TLS-specific call-home transport 2034 configuration."; 2035 container tcp-client-parameters { 2036 description 2037 "A wrapper around the TCP client parameters 2038 to avoid name collisions."; 2039 uses tcpc:tcp-client-grouping { 2040 refine "remote-port" { 2041 default "4335"; 2042 description 2043 "The NETCONF server will attempt to connect 2044 to the IANA-assigned well-known port for 2045 'netconf-ch-tls' (4335) if no value is 2046 specified."; 2047 } 2048 } 2049 } 2050 container tls-server-parameters { 2051 description 2052 "A wrapper around the TLS server parameters to 2053 avoid name collisions."; 2054 uses tlss:tls-server-grouping { 2055 refine "client-authentication" { 2056 must 'ca-certs or ee-certs'; 2057 description 2058 "NETCONF/TLS servers MUST validate client 2059 certificates. This configures certificates 2060 at the socket-level (i.e. bags), more 2061 discriminating client-certificate checks 2062 SHOULD be implemented by the application."; 2063 reference 2064 "RFC 7589: 2065 Using the NETCONF Protocol over Transport Layer 2066 Security (TLS) with Mutual X.509 Authentication"; 2067 } 2068 } 2069 } 2070 container netconf-server-parameters { 2071 description 2072 "A wrapper around the NETCONF server parameters 2073 to avoid name collisions."; 2074 uses ncs:netconf-server-grouping; 2075 } 2076 } 2077 } 2078 } 2079 } 2081 grouping netconf-server-app-grouping { 2082 description 2083 "A reusable grouping for configuring a NETCONF server 2084 application that supports both 'listen' and 'call-home' 2085 protocol stacks for a multiplicity of connections."; 2086 container listen { 2087 if-feature "ssh-listen or tls-listen"; 2088 presence 2089 "Enables server to listen for NETCONF client connections."; 2090 description 2091 "Configures listen behavior"; 2092 leaf idle-timeout { 2093 type uint16; 2094 units "seconds"; 2095 default 3600; // one hour 2096 description 2097 "Specifies the maximum number of seconds that a NETCONF 2098 session may remain idle. A NETCONF session will be 2099 dropped if it is idle for an interval longer than this 2100 number of seconds. If set to zero, then the server 2101 will never drop a session because it is idle. Sessions 2102 that have a notification subscription active are never 2103 dropped."; 2104 } 2105 list endpoint { 2106 key "name"; 2107 min-elements 1; 2108 description 2109 "List of endpoints to listen for NETCONF connections."; 2110 leaf name { 2111 type string; 2112 description 2113 "An arbitrary name for the NETCONF listen endpoint."; 2114 } 2115 uses netconf-server-listen-stack-grouping; 2116 } 2117 } 2118 container call-home { 2119 if-feature "ssh-call-home or tls-call-home"; 2120 presence 2121 "Enables the NETCONF server to initiate the underlying 2122 transport connection to NETCONF clients."; 2123 description "Configures call home behavior."; 2124 list netconf-client { 2125 key "name"; 2126 min-elements 1; 2127 description 2128 "List of NETCONF clients the NETCONF server is to 2129 maintain simultaneous call-home connections with."; 2130 leaf name { 2131 type string; 2132 description 2133 "An arbitrary name for the remote NETCONF client."; 2134 } 2135 container endpoints { 2136 description 2137 "Container for the list of endpoints."; 2138 list endpoint { 2139 key "name"; 2140 min-elements 1; 2141 ordered-by user; 2142 description 2143 "A non-empty user-ordered list of endpoints for this 2144 NETCONF server to try to connect to in sequence. 2145 Defining more than one enables high-availability."; 2146 leaf name { 2147 type string; 2148 description 2149 "An arbitrary name for this endpoint."; 2150 } 2151 uses netconf-server-callhome-stack-grouping; 2152 } 2153 } 2154 container connection-type { 2155 description 2156 "Indicates the NETCONF server's preference for how the 2157 NETCONF connection is maintained."; 2158 choice connection-type { 2159 mandatory true; 2160 description 2161 "Selects between available connection types."; 2162 case persistent-connection { 2163 container persistent { 2164 presence "Indicates that a persistent connection is 2165 to be maintained."; 2166 description 2167 "Maintain a persistent connection to the NETCONF 2168 client. If the connection goes down, immediately 2169 start trying to reconnect to the NETCONF client, 2170 using the reconnection strategy. 2172 This connection type minimizes any NETCONF client 2173 to NETCONF server data-transfer delay, albeit at 2174 the expense of holding resources longer."; 2175 } 2176 } 2177 case periodic-connection { 2178 container periodic { 2179 presence "Indicates that a periodic connection is 2180 to be maintained."; 2181 description 2182 "Periodically connect to the NETCONF client. 2184 This connection type increases resource 2185 utilization, albeit with increased delay in 2186 NETCONF client to NETCONF client interactions. 2188 The NETCONF client SHOULD gracefully close the 2189 connection using upon completing 2190 planned activities. If the NETCONF session is 2191 not closed gracefully, the NETCONF server MUST 2192 immediately attempt to reestablish the connection. 2194 In the case that the previous connection is still 2195 active (i.e., the NETCONF client has not closed 2196 it yet), establishing a new connection is NOT 2197 RECOMMENDED."; 2198 leaf period { 2199 type uint16; 2200 units "minutes"; 2201 default "60"; 2202 description 2203 "Duration of time between periodic connections."; 2204 } 2205 leaf anchor-time { 2206 type yang:date-and-time { 2207 // constrained to minute-level granularity 2208 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}' 2209 + '(Z|[\+\-]\d{2}:\d{2})'; 2210 } 2211 description 2212 "Designates a timestamp before or after which a 2213 series of periodic connections are determined. 2214 The periodic connections occur at a whole 2215 multiple interval from the anchor time. For 2216 example, for an anchor time is 15 minutes past 2217 midnight and a period interval of 24 hours, then 2218 a periodic connection will occur 15 minutes past 2219 midnight everyday."; 2220 } 2221 leaf idle-timeout { 2222 type uint16; 2223 units "seconds"; 2224 default 120; // two minutes 2225 description 2226 "Specifies the maximum number of seconds that 2227 a NETCONF session may remain idle. A NETCONF 2228 session will be dropped if it is idle for an 2229 interval longer than this number of seconds. 2230 If set to zero, then the server will never 2231 drop a session because it is idle."; 2232 } 2233 } 2234 } // case periodic-connection 2235 } // choice connection-type 2236 } // container connection-type 2237 container reconnect-strategy { 2238 description 2239 "The reconnection strategy directs how a NETCONF server 2240 reconnects to a NETCONF client, after discovering its 2241 connection to the client has dropped, even if due to a 2242 reboot. The NETCONF server starts with the specified 2243 endpoint and tries to connect to it max-attempts times 2244 before trying the next endpoint in the list (round 2245 robin)."; 2246 leaf start-with { 2247 type enumeration { 2248 enum first-listed { 2249 description 2250 "Indicates that reconnections should start with 2251 the first endpoint listed."; 2252 } 2253 enum last-connected { 2254 description 2255 "Indicates that reconnections should start with 2256 the endpoint last connected to. If no previous 2257 connection has ever been established, then the 2258 first endpoint configured is used. NETCONF 2259 servers SHOULD be able to remember the last 2260 endpoint connected to across reboots."; 2261 } 2262 enum random-selection { 2263 description 2264 "Indicates that reconnections should start with 2265 a random endpoint."; 2266 } 2267 } 2268 default "first-listed"; 2269 description 2270 "Specifies which of the NETCONF client's endpoints 2271 the NETCONF server should start with when trying 2272 to connect to the NETCONF client."; 2273 } 2274 leaf max-attempts { 2275 type uint8 { 2276 range "1..max"; 2277 } 2278 default "3"; 2279 description 2280 "Specifies the number times the NETCONF server tries 2281 to connect to a specific endpoint before moving on 2282 to the next endpoint in the list (round robin)."; 2283 } 2284 } // container reconnect-strategy 2285 } // list netconf-client 2286 } // container call-home 2287 } // grouping netconf-server-app-grouping 2289 // Protocol accessible node, for servers that implement 2290 // this module. 2291 container netconf-server { 2292 uses netconf-server-app-grouping; 2293 description 2294 "Top-level container for NETCONF server configuration."; 2295 } 2296 } 2298 2300 4. Security Considerations 2302 4.1. The "ietf-netconf-client" YANG Module 2304 The "ietf-netconf-client" YANG module defines data nodes that are 2305 designed to be accessed via YANG based management protocols, such as 2306 NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 2307 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 2308 with mutual authentication. 2310 The NETCONF access control model (NACM) [RFC8341] provides the means 2311 to restrict access for particular users to a pre-configured subset of 2312 all available protocol operations and content. 2314 None of the readable data nodes defined in this YANG module are 2315 considered sensitive or vulnerable in network environments. The NACM 2316 "default-deny-all" extension has not been set for any data nodes 2317 defined in this module. 2319 None of the writable data nodes defined in this YANG module are 2320 considered sensitive or vulnerable in network environments. The NACM 2321 "default-deny-write" extension has not been set for any data nodes 2322 defined in this module. 2324 This module does not define any RPCs, actions, or notifications, and 2325 thus the security consideration for such is not provided here. 2327 Please be aware that this module uses groupings defined in other RFCs 2328 that define data nodes that do set the NACM "default-deny-all" and 2329 "default-deny-write" extensions. 2331 4.2. The "ietf-netconf-server" YANG Module 2333 The "ietf-netconf-server" YANG module defines data nodes that are 2334 designed to be accessed via YANG based management protocols, such as 2335 NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 2336 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 2337 with mutual authentication. 2339 The NETCONF access control model (NACM) [RFC8341] provides the means 2340 to restrict access for particular users to a pre-configured subset of 2341 all available protocol operations and content. 2343 None of the readable data nodes defined in this YANG module are 2344 considered sensitive or vulnerable in network environments. The NACM 2345 "default-deny-all" extension has not been set for any data nodes 2346 defined in this module. 2348 None of the writable data nodes defined in this YANG module are 2349 considered sensitive or vulnerable in network environments. The NACM 2350 "default-deny-write" extension has not been set for any data nodes 2351 defined in this module. 2353 This module does not define any RPCs, actions, or notifications, and 2354 thus the security consideration for such is not provided here. 2356 Please be aware that this module uses groupings defined in other RFCs 2357 that define data nodes that do set the NACM "default-deny-all" and 2358 "default-deny-write" extensions. 2360 5. IANA Considerations 2362 5.1. The "IETF XML" Registry 2364 This document registers two URIs in the "ns" subregistry of the IETF 2365 XML Registry [RFC3688]. Following the format in [RFC3688], the 2366 following registrations are requested: 2368 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-client 2369 Registrant Contact: The IESG 2370 XML: N/A, the requested URI is an XML namespace. 2372 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server 2373 Registrant Contact: The IESG 2374 XML: N/A, the requested URI is an XML namespace. 2376 5.2. The "YANG Module Names" Registry 2378 This document registers two YANG modules in the YANG Module Names 2379 registry [RFC6020]. Following the format in [RFC6020], the following 2380 registrations are requested: 2382 name: ietf-netconf-client 2383 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-client 2384 prefix: ncc 2385 reference: RFC HHHH 2387 name: ietf-netconf-server 2388 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server 2389 prefix: ncs 2390 reference: RFC HHHH 2392 6. References 2394 6.1. Normative References 2396 [I-D.ietf-netconf-keystore] 2397 Watsen, K., "A YANG Data Model for a Keystore", Work in 2398 Progress, Internet-Draft, draft-ietf-netconf-keystore-20, 2399 20 August 2020, . 2402 [I-D.ietf-netconf-ssh-client-server] 2403 Watsen, K., "YANG Groupings for SSH Clients and SSH 2404 Servers", Work in Progress, Internet-Draft, draft-ietf- 2405 netconf-ssh-client-server-22, 20 August 2020, 2406 . 2409 [I-D.ietf-netconf-tcp-client-server] 2410 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 2411 and TCP Servers", Work in Progress, Internet-Draft, draft- 2412 ietf-netconf-tcp-client-server-08, 20 August 2020, 2413 . 2416 [I-D.ietf-netconf-tls-client-server] 2417 Watsen, K., "YANG Groupings for TLS Clients and TLS 2418 Servers", Work in Progress, Internet-Draft, draft-ietf- 2419 netconf-tls-client-server-22, 20 August 2020, 2420 . 2423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2424 Requirement Levels", BCP 14, RFC 2119, 2425 DOI 10.17487/RFC2119, March 1997, 2426 . 2428 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2429 the Network Configuration Protocol (NETCONF)", RFC 6020, 2430 DOI 10.17487/RFC6020, October 2010, 2431 . 2433 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2434 and A. Bierman, Ed., "Network Configuration Protocol 2435 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2436 . 2438 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2439 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2440 . 2442 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2443 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2444 . 2446 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 2447 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 2448 December 2014, . 2450 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2451 NETCONF Protocol over Transport Layer Security (TLS) with 2452 Mutual X.509 Authentication", RFC 7589, 2453 DOI 10.17487/RFC7589, June 2015, 2454 . 2456 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2457 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2458 . 2460 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2461 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2462 May 2017, . 2464 6.2. Informative References 2466 [I-D.ietf-netconf-crypto-types] 2467 Watsen, K., "YANG Data Types and Groupings for 2468 Cryptography", Work in Progress, Internet-Draft, draft- 2469 ietf-netconf-crypto-types-18, 20 August 2020, 2470 . 2473 [I-D.ietf-netconf-http-client-server] 2474 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 2475 Servers", Work in Progress, Internet-Draft, draft-ietf- 2476 netconf-http-client-server-05, 20 August 2020, 2477 . 2480 [I-D.ietf-netconf-netconf-client-server] 2481 Watsen, K., "NETCONF Client and Server Models", Work in 2482 Progress, Internet-Draft, draft-ietf-netconf-netconf- 2483 client-server-21, 20 August 2020, 2484 . 2487 [I-D.ietf-netconf-restconf-client-server] 2488 Watsen, K., "RESTCONF Client and Server Models", Work in 2489 Progress, Internet-Draft, draft-ietf-netconf-restconf- 2490 client-server-21, 20 August 2020, 2491 . 2494 [I-D.ietf-netconf-trust-anchors] 2495 Watsen, K., "A YANG Data Model for a Truststore", Work in 2496 Progress, Internet-Draft, draft-ietf-netconf-trust- 2497 anchors-13, 20 August 2020, . 2500 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2501 DOI 10.17487/RFC3688, January 2004, 2502 . 2504 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2505 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2506 . 2508 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 2509 RFC 8071, DOI 10.17487/RFC8071, February 2017, 2510 . 2512 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2513 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2514 . 2516 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2517 Access Control Model", STD 91, RFC 8341, 2518 DOI 10.17487/RFC8341, March 2018, 2519 . 2521 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2522 and R. Wilton, "Network Management Datastore Architecture 2523 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2524 . 2526 Appendix A. Change Log 2528 This section is to be removed before publishing as an RFC. 2530 A.1. 00 to 01 2532 * Renamed "keychain" to "keystore". 2534 A.2. 01 to 02 2536 * Added to ietf-netconf-client ability to connected to a cluster of 2537 endpoints, including a reconnection-strategy. 2539 * Added to ietf-netconf-client the ability to configure connection- 2540 type and also keep-alive strategy. 2542 * Updated both modules to accommodate new groupings in the ssh/tls 2543 drafts. 2545 A.3. 02 to 03 2547 * Refined use of tls-client-grouping to add a must statement 2548 indicating that the TLS client must specify a client-certificate. 2550 * Changed 'netconf-client' to be a grouping (not a container). 2552 A.4. 03 to 04 2554 * Added RFC 8174 to Requirements Language Section. 2556 * Replaced refine statement in ietf-netconf-client to add a 2557 mandatory true. 2559 * Added refine statement in ietf-netconf-server to add a must 2560 statement. 2562 * Now there are containers and groupings, for both the client and 2563 server models. 2565 A.5. 04 to 05 2567 * Now tree diagrams reference ietf-netmod-yang-tree-diagrams 2569 * Updated examples to inline key and certificates (no longer a 2570 leafref to keystore) 2572 A.6. 05 to 06 2574 * Fixed change log missing section issue. 2576 * Updated examples to match latest updates to the crypto-types, 2577 trust-anchors, and keystore drafts. 2579 * Reduced line length of the YANG modules to fit within 69 columns. 2581 A.7. 06 to 07 2583 * Removed "idle-timeout" from "persistent" connection config. 2585 * Added "random-selection" for reconnection-strategy's "starts-with" 2586 enum. 2588 * Replaced "connection-type" choice default (persistent) with 2589 "mandatory true". 2591 * Reduced the periodic-connection's "idle-timeout" from 5 to 2 2592 minutes. 2594 * Replaced reconnect-timeout with period/anchor-time combo. 2596 A.8. 07 to 08 2598 * Modified examples to be compatible with new crypto-types algs 2600 A.9. 08 to 09 2602 * Corrected use of "mandatory true" for "address" leafs. 2604 * Updated examples to reflect update to groupings defined in the 2605 keystore draft. 2607 * Updated to use groupings defined in new TCP and HTTP drafts. 2609 * Updated copyright date, boilerplate template, affiliation, and 2610 folding algorithm. 2612 A.10. 09 to 10 2614 * Reformatted YANG modules. 2616 A.11. 10 to 11 2618 * Adjusted for the top-level "demux container" added to groupings 2619 imported from other modules. 2621 * Added "must" expressions to ensure that keepalives are not 2622 configured for "periodic" connections. 2624 * Updated the boilerplate text in module-level "description" 2625 statement to match copyeditor convention. 2627 * Moved "expanded" tree diagrams to the Appendix. 2629 A.12. 11 to 12 2631 * Removed the "Design Considerations" section. 2633 * Removed the 'must' statement limiting keepalives in periodic 2634 connections. 2636 * Updated models and examples to reflect removal of the "demux" 2637 containers in the imported models. 2639 * Updated the "periodic-connnection" description statements to be 2640 more like the RESTCONF draft, especially where it described 2641 dropping the underlying TCP connection. 2643 * Updated text to better reference where certain examples come from 2644 (e.g., which Section in which draft). 2646 * In the server model, commented out the "must 'pinned-ca-certs or 2647 pinned-client-certs'" statement to reflect change made in the TLS 2648 draft whereby the trust anchors MAY be defined externally. 2650 * Replaced the 'listen', 'initiate', and 'call-home' features with 2651 boolean expressions. 2653 A.13. 12 to 13 2655 * Updated to reflect changes in trust-anchors drafts (e.g., s/trust- 2656 anchors/truststore/g + s/pinned.//) 2658 A.14. 13 to 14 2660 * Adjusting from change in TLS client model (removing the top-level 2661 'certificate' container), by swapping refining-in a 'mandatory 2662 true' statement with a 'must' statement outside the 'uses' 2663 statement. 2665 * Updated examples to reflect ietf-crypto-types change (e.g., 2666 identities --> enumerations) 2668 A.15. 14 to 15 2670 * Refactored both the client and server modules similar to how the 2671 ietf-restconf-server module was refactored in -13 of that draft, 2672 and the ietf-restconf-client grouping. 2674 A.16. 15 to 16 2676 * Added refinement to make "cert-to-name/fingerprint" be mandatory 2677 false. 2679 * Commented out refinement to "tls-server-grouping/client- 2680 authentication" until a better "must" expression is defined. 2682 A.17. 16 to 17 2683 * Updated examples to include the "*-key-format" nodes. 2685 * Updated examples to remove the "required" nodes. 2687 * Updated examples to remove the "client-auth-defined-elsewhere" 2688 nodes. 2690 A.18. 17 to 18 2692 * Updated examples to reflect new "bag" addition to truststore. 2694 A.19. 18 to 19 2696 * Updated examples to remove the 'algorithm' nodes. 2698 * Updated examples to reflect the new TLS keepalives structure. 2700 * Added keepalives to the tcp-client-parameters section in the 2701 netconf-server SSH-based call-home example. 2703 * Added a TLS-based call-home example to the netconf-client example. 2705 * Added a "Note to Reviewers" note to first page. 2707 A.20. 19 to 20 2709 * Expanded "Data Model Overview section(s) [remove "wall" of tree 2710 diagrams]. 2712 * Removed expanded tree diagrams that were listed in the Appendix. 2714 * Updated the Security Considerations section. 2716 A.21. 20 to 21 2718 * Cleaned up titles in the IANA Considerations section 2720 * Fixed issues found by the SecDir review of the "keystore" draft. 2722 A.22. 21 to 22 2724 * Addressed comments raised by YANG Doctor in the ct/ts/ks drafts. 2726 Acknowledgements 2728 The authors would like to thank for following for lively discussions 2729 on list and in the halls (ordered by last name): Andy Bierman, Martin 2730 Bjorklund, Benoit Claise, Ramkumar Dhanapal, Mehmet Ersue, Balazs 2731 Kovacs, David Lamparter, Ladislav Lhotka, Alan Luchuk, Radek Krejci, 2732 Tom Petch, Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert 2733 Wijnen. 2735 Author's Address 2737 Kent Watsen 2738 Watsen Networks 2740 Email: kent+ietf@watsen.net