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