idnits 2.17.1 draft-ietf-netconf-netconf-client-server-25.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 (7 March 2022) is 781 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-23 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-26 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-11 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-26 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-21 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-08 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-24 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-24 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-16 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 7 March 2022 5 Expires: 8 September 2022 7 NETCONF Client and Server Models 8 draft-ietf-netconf-netconf-client-server-25 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-client- 37 server 39 * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- 40 server 42 * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- 43 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 * 2022-03-07 --> 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 8 September 2022. 75 Copyright Notice 77 Copyright (c) 2022 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 Revised BSD License text as 86 described in Section 4.e of the Trust Legal Provisions and are 87 provided without warranty as described in the Revised BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 92 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 4 93 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 94 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 95 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 96 2. The "ietf-netconf-client" Module . . . . . . . . . . . . . . 6 97 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 98 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 10 99 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 100 3. The "ietf-netconf-server" Module . . . . . . . . . . . . . . 25 101 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 25 102 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 30 103 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 36 104 4. Security Considerations . . . . . . . . . . . . . . . . . . . 50 105 4.1. The "ietf-netconf-client" YANG Module . . . . . . . . . . 50 106 4.2. The "ietf-netconf-server" YANG Module . . . . . . . . . . 51 107 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 108 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 51 109 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 52 110 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 111 6.1. Normative References . . . . . . . . . . . . . . . . . . 52 112 6.2. Informative References . . . . . . . . . . . . . . . . . 53 113 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 55 114 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 55 115 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 55 116 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 55 117 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 55 118 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 56 119 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 56 120 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 56 121 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 56 122 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 56 123 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 57 124 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 57 125 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 57 126 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 57 127 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 58 128 A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 58 129 A.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 58 130 A.17. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 58 131 A.18. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 58 132 A.19. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 58 133 A.20. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 59 134 A.21. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 59 135 A.22. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 59 136 A.23. 22 to 23 . . . . . . . . . . . . . . . . . . . . . . . . 59 137 A.24. 23 to 24 . . . . . . . . . . . . . . . . . . . . . . . . 59 138 A.25. 24 to 25 . . . . . . . . . . . . . . . . . . . . . . . . 59 139 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60 140 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60 142 1. Introduction 144 This document defines two YANG [RFC7950] modules, one module to 145 configure a NETCONF [RFC6241] client and the other module to 146 configure a NETCONF server. Both modules support both NETCONF over 147 SSH [RFC6242] and NETCONF over TLS [RFC7589] and NETCONF Call Home 148 connections [RFC8071]. 150 1.1. Relation to other RFCs 152 This document presents one or more YANG modules [RFC7950] that are 153 part of a collection of RFCs that work together to, ultimately, 154 enable the configuration of the clients and servers of both the 155 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 157 The modules have been defined in a modular fashion to enable their 158 use by other efforts, some of which are known to be in progress at 159 the time of this writing, with many more expected to be defined in 160 time. 162 The normative dependency relationship between the various RFCs in the 163 collection is presented in the below diagram. The labels in the 164 diagram represent the primary purpose provided by each RFC. 165 Hyperlinks to each RFC are provided below the diagram. 167 crypto-types 168 ^ ^ 169 / \ 170 / \ 171 truststore keystore 172 ^ ^ ^ ^ 173 | +---------+ | | 174 | | | | 175 | +------------+ | 176 tcp-client-server | / | | 177 ^ ^ ssh-client-server | | 178 | | ^ tls-client-server 179 | | | ^ ^ http-client-server 180 | | | | | ^ 181 | | | +-----+ +---------+ | 182 | | | | | | 183 | +-----------|--------|--------------+ | | 184 | | | | | | 185 +-----------+ | | | | | 186 | | | | | | 187 | | | | | | 188 netconf-client-server restconf-client-server 190 +=======================+===========================================+ 191 |Label in Diagram | Originating RFC | 192 +=======================+===========================================+ 193 |crypto-types | [I-D.ietf-netconf-crypto-types] | 194 +-----------------------+-------------------------------------------+ 195 |truststore | [I-D.ietf-netconf-trust-anchors] | 196 +-----------------------+-------------------------------------------+ 197 |keystore | [I-D.ietf-netconf-keystore] | 198 +-----------------------+-------------------------------------------+ 199 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 200 +-----------------------+-------------------------------------------+ 201 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 202 +-----------------------+-------------------------------------------+ 203 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 204 +-----------------------+-------------------------------------------+ 205 |http-client-server | [I-D.ietf-netconf-http-client-server] | 206 +-----------------------+-------------------------------------------+ 207 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 208 +-----------------------+-------------------------------------------+ 209 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 210 +-----------------------+-------------------------------------------+ 212 Table 1: Label to RFC Mapping 214 1.2. Specification Language 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 1.3. Adherence to the NMDA 224 This document is compliant with the Network Management Datastore 225 Architecture (NMDA) [RFC8342]. For instance, as described in 226 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore], 227 trust anchors and keys installed during manufacturing are expected to 228 appear in . 230 1.4. Conventions 232 Various examples used in this document use a placeholder value for 233 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 234 This placeholder value is used as real base64 encoded structures are 235 often many lines long and hence distracting to the example being 236 presented. 238 2. The "ietf-netconf-client" Module 240 The NETCONF client model presented in this section supports both 241 clients initiating connections to servers, as well as clients 242 listening for connections from servers calling home, using either the 243 SSH and TLS transport protocols. 245 YANG feature statements are used to enable implementations to 246 advertise which potentially uncommon parts of the model the NETCONF 247 client supports. 249 2.1. Data Model Overview 251 This section provides an overview of the "ietf-netconf-client" module 252 in terms of its features and groupings. 254 2.1.1. Features 256 The following diagram lists all the "feature" statements defined in 257 the "ietf-netconf-client" module: 259 Features: 260 +-- ssh-initiate 261 +-- tls-initiate 262 +-- ssh-listen 263 +-- tls-listen 265 | The diagram above uses syntax that is similar to but not 266 | defined in [RFC8340]. 268 2.1.2. Groupings 270 The "ietf-netconf-client" module defines the following "grouping" 271 statements: 273 * netconf-client-grouping 274 * netconf-client-initiate-stack-grouping 275 * netconf-client-listen-stack-grouping 276 * netconf-client-app-grouping 278 Each of these groupings are presented in the following subsections. 280 2.1.2.1. The "netconf-client-grouping" Grouping 282 The following tree diagram [RFC8340] illustrates the "netconf-client- 283 grouping" grouping: 285 grouping netconf-client-grouping ---> 287 Comments: 289 * This grouping does not define any nodes, but is maintained so that 290 downstream modules can augment nodes into it if needed. 292 * The "netconf-client-grouping" defines, if it can be called that, 293 the configuration for just "NETCONF" part of a protocol stack. It 294 does not, for instance, define any configuration for the "TCP", 295 "SSH" or "TLS" protocol layers (for that, see Section 2.1.2.2 and 296 Section 2.1.2.3). 298 2.1.2.2. The "netconf-client-initiate-stack-grouping" Grouping 300 The following tree diagram [RFC8340] illustrates the "netconf-client- 301 initiate-stack-grouping" grouping: 303 grouping netconf-client-initiate-stack-grouping 304 +-- (transport) 305 +--:(ssh) {ssh-initiate}? 306 | +-- ssh 307 | +-- tcp-client-parameters 308 | | +---u tcpc:tcp-client-grouping 309 | +-- ssh-client-parameters 310 | | +---u sshc:ssh-client-grouping 311 | +-- netconf-client-parameters 312 | +--u ncc:netconf-client-grouping 313 +--:(tls) {tls-initiate}? 314 +-- tls 315 +-- tcp-client-parameters 316 | +---u tcpc:tcp-client-grouping 317 +-- tls-client-parameters 318 | +---u tlsc:tls-client-grouping 319 +-- netconf-client-parameters 320 +---u ncc:netconf-client-grouping 322 Comments: 324 * The "netconf-client-initiate-stack-grouping" defines the 325 configuration for a full NETCONF protocol stack, for NETCONF 326 clients that initiate connections to NETCONF servers, as opposed 327 to receiving call-home [RFC8071] connections. 329 * The "transport" choice node enables both the SSH and TLS 330 transports to be configured, with each option enabled by a 331 "feature" statement. 333 * For the referenced grouping statement(s): 335 - The "tcp-client-grouping" grouping is discussed in 336 Section 3.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 337 - The "ssh-client-grouping" grouping is discussed in 338 Section 3.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 339 - The "tls-client-grouping" grouping is discussed in 340 Section 3.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 341 - The "netconf-client-grouping" grouping is discussed in 342 Section 2.1.2.1 in this document. 344 2.1.2.3. The "netconf-client-listen-stack-grouping" Grouping 346 The following tree diagram [RFC8340] illustrates the "netconf-client- 347 listen-stack-grouping" grouping: 349 grouping netconf-client-listen-stack-grouping 350 +-- (transport) 351 +--:(ssh) {ssh-listen}? 352 | +-- ssh 353 | +-- tcp-server-parameters 354 | | +---u tcps:tcp-server-grouping 355 | +-- ssh-client-parameters 356 | | +---u sshc:ssh-client-grouping 357 | +-- netconf-client-parameters 358 | +--u ncc:netconf-client-grouping 359 +--:(tls) {tls-listen}? 360 +-- tls 361 +-- tcp-server-parameters 362 | +---u tcps:tcp-server-grouping 363 +-- tls-client-parameters 364 | +---u tlsc:tls-client-grouping 365 +-- netconf-client-parameters 366 +---u ncc:netconf-client-grouping 368 Comments: 370 * The "netconf-client-listen-stack-grouping" defines the 371 configuration for a full NETCONF protocol stack, for NETCONF 372 clients that receive call-home [RFC8071] connections from NETCONF 373 servers. 375 * The "transport" choice node enables both the SSH and TLS 376 transports to be configured, with each option enabled by a 377 "feature" statement. 379 * For the referenced grouping statement(s): 381 - The "tcp-server-grouping" grouping is discussed in 382 Section 4.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 384 - The "ssh-client-grouping" grouping is discussed in 385 Section 3.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 386 - The "tls-client-grouping" grouping is discussed in 387 Section 3.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 388 - The "netconf-client-grouping" grouping is discussed in 389 Section 2.1.2.1 in this document. 391 2.1.2.4. The "netconf-client-app-grouping" Grouping 393 The following tree diagram [RFC8340] illustrates the "netconf-client- 394 app-grouping" grouping: 396 grouping netconf-client-app-grouping 397 +-- initiate! {ssh-initiate or tls-initiate}? 398 | +-- netconf-server* [name] 399 | +-- name? string 400 | +-- endpoints 401 | | +-- endpoint* [name] 402 | | +-- name? string 403 | | +---u netconf-client-initiate-stack-grouping 404 | +-- connection-type 405 | | +-- (connection-type) 406 | | +--:(persistent-connection) 407 | | | +-- persistent! 408 | | +--:(periodic-connection) 409 | | +-- periodic! 410 | | +-- period? uint16 411 | | +-- anchor-time? yang:date-and-time 412 | | +-- idle-timeout? uint16 413 | +-- reconnect-strategy 414 | +-- start-with? enumeration 415 | +-- max-attempts? uint8 416 +-- listen! {ssh-listen or tls-listen}? 417 +-- idle-timeout? uint16 418 +-- endpoint* [name] 419 +-- name? string 420 +---u netconf-client-listen-stack-grouping 422 Comments: 424 * The "netconf-client-app-grouping" defines the configuration for a 425 NETCONF client that supports both initiating connections to 426 NETCONF servers as well as receiving call-home connections from 427 NETCONF servers. 429 * Both the "initiate" and "listen" subtrees must be enabled by 430 "feature" statements. 432 * For the referenced grouping statement(s): 434 - The "netconf-client-initiate-stack-grouping" grouping is 435 discussed in Section 2.1.2.2 in this document. 436 - The "netconf-client-listen-stack-grouping" grouping is 437 discussed in Section 2.1.2.3 in this document. 439 2.1.3. Protocol-accessible Nodes 441 The following tree diagram [RFC8340] lists all the protocol- 442 accessible nodes defined in the "ietf-netconf-client" module: 444 module: ietf-netconf-client 445 +--rw netconf-client 446 +---u netconf-client-app-grouping 448 Comments: 450 * Protocol-accessible nodes are those nodes that are accessible when 451 the module is "implemented", as described in Section 5.6.5 of 452 [RFC7950]. 454 * For the "ietf-netconf-client" module, the protocol-accessible 455 nodes are an instance of the "netconf-client-app-grouping" 456 discussed in Section 2.1.2.4 grouping. 458 * The reason for why "netconf-client-app-grouping" exists separate 459 from the protocol-accessible nodes definition is so as to enable 460 instances of netconf-client-app-grouping to be instantiated in 461 other locations, as may be needed or desired by some modules. 463 2.2. Example Usage 465 The following example illustrates configuring a NETCONF client to 466 initiate connections, using both the SSH and TLS transport protocols, 467 as well as to listen for call-home connections, again using both the 468 SSH and TLS transport protocols. 470 This example is consistent with the examples presented in Section 2.2 471 of [I-D.ietf-netconf-trust-anchors] and Section 2.2 of 472 [I-D.ietf-netconf-keystore]. 474 =============== NOTE: '\' line wrapping per RFC 8792 ================ 476 479 480 481 482 corp-fw1 483 484 485 corp-fw1.example.com 486 487 488 corp-fw1.example.com 489 490 15 491 3 492 30 493 494 495 496 497 foobar 498 499 ssh-rsa-key 501 502 503 504 505 trusted-server-ca-certs 507 508 509 trusted-server-ee-certs 511 512 513 514 30 515 3 516 517 518 519 520 521 522 523 524 corp-fw2.example.com 525 526 527 corp-fw2.example.com 528 529 15 530 3 531 30 532 533 534 535 536 537 538 rsa-asymmetric-key 540 ex-rsa-cert 541 542 543 544 545 546 trusted-server-ca-certs 548 549 550 trusted-server-ee-certs 552 553 554 555 556 30 557 3 558 559 560 561 562 563 564 565 566 567 568 569 570 571 last-connected 572 573 574 575 576 577 578 Intranet-facing SSH listener 579 580 581 192.0.2.7 582 583 584 585 foobar 586 587 ssh-rsa-key 588 589 590 591 592 trusted-server-ca-certs 594 595 596 trusted-server-ee-certs 598 599 600 trusted-ssh-public-keys 602 603 604 605 606 607 608 609 610 611 Intranet-facing TLS listener 612 613 614 192.0.2.7 615 616 617 618 619 620 rsa-asymmetric-key 621 ex-rsa-cert 622 624 625 626 627 628 trusted-server-ca-certs 630 631 632 trusted-server-ee-certs 634 635 636 637 638 639 640 641 642 643 644 645 646 648 2.3. YANG Module 650 This YANG module has normative references to [RFC6242], [RFC6991], 651 [RFC7589], [RFC8071], [I-D.ietf-netconf-tcp-client-server], 652 [I-D.ietf-netconf-ssh-client-server], and 653 [I-D.ietf-netconf-tls-client-server]. 655 file "ietf-netconf-client@2022-03-07.yang" 657 module ietf-netconf-client { 658 yang-version 1.1; 659 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-client"; 660 prefix ncc; 662 import ietf-yang-types { 663 prefix yang; 664 reference 665 "RFC 6991: Common YANG Data Types"; 666 } 668 import ietf-tcp-client { 669 prefix tcpc; 670 reference 671 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 673 } 675 import ietf-tcp-server { 676 prefix tcps; 677 reference 678 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 679 } 681 import ietf-ssh-client { 682 prefix sshc; 683 revision-date 2022-03-07; // stable grouping definitions 684 reference 685 "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers"; 686 } 688 import ietf-tls-client { 689 prefix tlsc; 690 revision-date 2022-03-07; // stable grouping definitions 691 reference 692 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers"; 693 } 695 organization 696 "IETF NETCONF (Network Configuration) Working Group"; 698 contact 699 "WG Web: https://datatracker.ietf.org/wg/netconf 700 WG List: NETCONF WG list 701 Author: Kent Watsen 702 Author: Gary Wu "; 704 description 705 "This module contains a collection of YANG definitions 706 for configuring NETCONF clients. 708 Copyright (c) 2021 IETF Trust and the persons identified 709 as authors of the code. All rights reserved. 711 Redistribution and use in source and binary forms, with 712 or without modification, is permitted pursuant to, and 713 subject to the license terms contained in, the Revised 714 BSD License set forth in Section 4.c of the IETF Trust's 715 Legal Provisions Relating to IETF Documents 716 (https://trustee.ietf.org/license-info). 718 This version of this YANG module is part of RFC HHHH 719 (https://www.rfc-editor.org/info/rfcHHHH); see the RFC 720 itself for full legal notices. 722 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 723 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 724 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 725 are to be interpreted as described in BCP 14 (RFC 2119) 726 (RFC 8174) when, and only when, they appear in all 727 capitals, as shown here."; 729 revision 2022-03-07 { 730 description 731 "Initial version"; 732 reference 733 "RFC HHHH: NETCONF Client and Server Models"; 734 } 736 // Features 738 feature ssh-initiate { 739 description 740 "The 'ssh-initiate' feature indicates that the NETCONF client 741 supports initiating SSH connections to NETCONF servers."; 742 reference 743 "RFC 6242: 744 Using the NETCONF Protocol over Secure Shell (SSH)"; 745 } 747 feature tls-initiate { 748 description 749 "The 'tls-initiate' feature indicates that the NETCONF client 750 supports initiating TLS connections to NETCONF servers."; 751 reference 752 "RFC 7589: Using the NETCONF Protocol over Transport 753 Layer Security (TLS) with Mutual X.509 Authentication"; 754 } 756 feature ssh-listen { 757 description 758 "The 'ssh-listen' feature indicates that the NETCONF client 759 supports opening a port to listen for incoming NETCONF 760 server call-home SSH connections."; 761 reference 762 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 763 } 765 feature tls-listen { 766 description 767 "The 'tls-listen' feature indicates that the NETCONF client 768 supports opening a port to listen for incoming NETCONF 769 server call-home TLS connections."; 771 reference 772 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 773 } 775 // Groupings 777 grouping netconf-client-grouping { 778 description 779 "A reusable grouping for configuring a NETCONF client 780 without any consideration for how underlying transport 781 sessions are established. 783 This grouping currently does not define any nodes."; 784 } 786 grouping netconf-client-initiate-stack-grouping { 787 description 788 "A reusable grouping for configuring a NETCONF client 789 'initiate' protocol stack for a single connection."; 790 choice transport { 791 mandatory true; 792 description 793 "Selects between available transports."; 794 case ssh { 795 if-feature "ssh-initiate"; 796 container ssh { 797 description 798 "Specifies IP and SSH specific configuration 799 for the connection."; 800 container tcp-client-parameters { 801 description 802 "A wrapper around the TCP client parameters 803 to avoid name collisions."; 804 uses tcpc:tcp-client-grouping { 805 refine "remote-port" { 806 default "830"; 807 description 808 "The NETCONF client will attempt to connect 809 to the IANA-assigned well-known port value 810 for 'netconf-ssh' (830) if no value is 811 specified."; 812 } 813 } 814 } 815 container ssh-client-parameters { 816 description 817 "A wrapper around the SSH client parameters to 818 avoid name collisions."; 820 uses sshc:ssh-client-grouping; 821 } 822 container netconf-client-parameters { 823 description 824 "A wrapper around the NETCONF client parameters 825 to avoid name collisions."; 826 uses ncc:netconf-client-grouping; 827 } 828 } 829 } 830 case tls { 831 if-feature "tls-initiate"; 832 container tls { 833 description 834 "Specifies IP and TLS specific configuration 835 for the connection."; 836 container tcp-client-parameters { 837 description 838 "A wrapper around the TCP client parameters 839 to avoid name collisions."; 840 uses tcpc:tcp-client-grouping { 841 refine "remote-port" { 842 default "6513"; 843 description 844 "The NETCONF client will attempt to connect 845 to the IANA-assigned well-known port value 846 for 'netconf-tls' (6513) if no value is 847 specified."; 848 } 849 } 850 } 851 container tls-client-parameters { 852 must client-identity { 853 description 854 "NETCONF/TLS clients MUST pass some 855 authentication credentials."; 856 } 857 description 858 "A wrapper around the TLS client parameters 859 to avoid name collisions."; 860 uses tlsc:tls-client-grouping; 861 } 862 container netconf-client-parameters { 863 description 864 "A wrapper around the NETCONF client parameters 865 to avoid name collisions."; 866 uses ncc:netconf-client-grouping; 867 } 869 } 870 } 871 } 872 } // netconf-client-initiate-stack-grouping 874 grouping netconf-client-listen-stack-grouping { 875 description 876 "A reusable grouping for configuring a NETCONF client 877 'listen' protocol stack for a single connection. The 878 'listen' stack supports call home connections, as 879 described in RFC 8071"; 880 reference 881 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 882 choice transport { 883 mandatory true; 884 description 885 "Selects between available transports."; 886 case ssh { 887 if-feature "ssh-listen"; 888 container ssh { 889 description 890 "SSH-specific listening configuration for inbound 891 connections."; 892 container tcp-server-parameters { 893 description 894 "A wrapper around the TCP server parameters 895 to avoid name collisions."; 896 uses tcps:tcp-server-grouping { 897 refine "local-port" { 898 default "4334"; 899 description 900 "The NETCONF client will listen on the IANA- 901 assigned well-known port for 'netconf-ch-ssh' 902 (4334) if no value is specified."; 903 } 904 } 905 } 906 container ssh-client-parameters { 907 description 908 "A wrapper around the SSH client parameters 909 to avoid name collisions."; 910 uses sshc:ssh-client-grouping; 911 } 912 container netconf-client-parameters { 913 description 914 "A wrapper around the NETCONF client parameters 915 to avoid name collisions."; 916 uses ncc:netconf-client-grouping; 918 } 919 } 920 } 921 case tls { 922 if-feature "tls-listen"; 923 container tls { 924 description 925 "TLS-specific listening configuration for inbound 926 connections."; 927 container tcp-server-parameters { 928 description 929 "A wrapper around the TCP server parameters 930 to avoid name collisions."; 931 uses tcps:tcp-server-grouping { 932 refine "local-port" { 933 default "4334"; 934 description 935 "The NETCONF client will listen on the IANA- 936 assigned well-known port for 'netconf-ch-ssh' 937 (4334) if no value is specified."; 938 } 939 } 940 } 941 container tls-client-parameters { 942 must client-identity { 943 description 944 "NETCONF/TLS clients MUST pass some 945 authentication credentials."; 946 } 947 description 948 "A wrapper around the TLS client parameters 949 to avoid name collisions."; 950 uses tlsc:tls-client-grouping; 951 } 952 container netconf-client-parameters { 953 description 954 "A wrapper around the NETCONF client parameters 955 to avoid name collisions."; 956 uses ncc:netconf-client-grouping; 957 } 958 } 959 } 960 } 961 } // netconf-client-listen-stack-grouping 963 grouping netconf-client-app-grouping { 964 description 965 "A reusable grouping for configuring a NETCONF client 966 application that supports both 'initiate' and 'listen' 967 protocol stacks for a multiplicity of connections."; 968 container initiate { 969 if-feature "ssh-initiate or tls-initiate"; 970 presence 971 "Indicates that client-initiated connections have been 972 configured. This statement is present so the mandatory 973 descendant nodes do not imply that this node must be 974 configured."; 975 description 976 "Configures client initiating underlying TCP connections."; 977 list netconf-server { 978 key "name"; 979 min-elements 1; 980 description 981 "List of NETCONF servers the NETCONF client is to 982 maintain simultaneous connections with."; 983 leaf name { 984 type string; 985 description 986 "An arbitrary name for the NETCONF server."; 987 } 988 container endpoints { 989 description 990 "Container for the list of endpoints."; 991 list endpoint { 992 key "name"; 993 min-elements 1; 994 ordered-by user; 995 description 996 "A user-ordered list of endpoints that the NETCONF 997 client will attempt to connect to in the specified 998 sequence. Defining more than one enables 999 high-availability."; 1000 leaf name { 1001 type string; 1002 description 1003 "An arbitrary name for the endpoint."; 1004 } 1005 uses netconf-client-initiate-stack-grouping; 1006 } // list endpoint 1007 } // container endpoints 1009 container connection-type { 1010 description 1011 "Indicates the NETCONF client's preference for how the 1012 NETCONF connection is maintained."; 1013 choice connection-type { 1014 mandatory true; 1015 description 1016 "Selects between available connection types."; 1017 case persistent-connection { 1018 container persistent { 1019 presence 1020 "Indicates that a persistent connection is to be 1021 maintained."; 1022 description 1023 "Maintain a persistent connection to the NETCONF 1024 server. If the connection goes down, immediately 1025 start trying to reconnect to the NETCONF server, 1026 using the reconnection strategy. 1028 This connection type minimizes any NETCONF server 1029 to NETCONF client data-transfer delay, albeit at 1030 the expense of holding resources longer."; 1031 } 1032 } 1033 case periodic-connection { 1034 container periodic { 1035 presence "Indicates that a periodic connection is 1036 to be maintained."; 1037 description 1038 "Periodically connect to the NETCONF server. 1040 This connection type increases resource 1041 utilization, albeit with increased delay in 1042 NETCONF server to NETCONF client interactions. 1044 The NETCONF client should close the underlying 1045 TCP connection upon completing planned activities. 1047 In the case that the previous connection is still 1048 active, establishing a new connection is NOT 1049 RECOMMENDED."; 1050 leaf period { 1051 type uint16; 1052 units "minutes"; 1053 default "60"; 1054 description 1055 "Duration of time between periodic connections."; 1056 } 1057 leaf anchor-time { 1058 type yang:date-and-time { 1059 // constrained to minute-level granularity 1060 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}' 1061 + '(Z|[\+\-]\d{2}:\d{2})'; 1063 } 1064 description 1065 "Designates a timestamp before or after which a 1066 series of periodic connections are determined. 1067 The periodic connections occur at a whole 1068 multiple interval from the anchor time. For 1069 example, for an anchor time is 15 minutes past 1070 midnight and a period interval of 24 hours, then 1071 a periodic connection will occur 15 minutes past 1072 midnight everyday."; 1073 } 1074 leaf idle-timeout { 1075 type uint16; 1076 units "seconds"; 1077 default 120; // two minutes 1078 description 1079 "Specifies the maximum number of seconds that 1080 a NETCONF session may remain idle. A NETCONF 1081 session will be dropped if it is idle for an 1082 interval longer then this number of seconds. 1083 If set to zero, then the NETCONF client will 1084 never drop a session because it is idle."; 1085 } 1086 } 1087 } 1088 } 1089 } 1090 container reconnect-strategy { 1091 description 1092 "The reconnection strategy directs how a NETCONF client 1093 reconnects to a NETCONF server, after discovering its 1094 connection to the server has dropped, even if due to a 1095 reboot. The NETCONF client starts with the specified 1096 endpoint and tries to connect to it max-attempts times 1097 before trying the next endpoint in the list (round 1098 robin)."; 1099 leaf start-with { 1100 type enumeration { 1101 enum first-listed { 1102 description 1103 "Indicates that reconnections should start with 1104 the first endpoint listed."; 1105 } 1106 enum last-connected { 1107 description 1108 "Indicates that reconnections should start with 1109 the endpoint last connected to. If no previous 1110 connection has ever been established, then the 1111 first endpoint configured is used. NETCONF 1112 clients SHOULD be able to remember the last 1113 endpoint connected to across reboots."; 1114 } 1115 enum random-selection { 1116 description 1117 "Indicates that reconnections should start with 1118 a random endpoint."; 1119 } 1120 } 1121 default "first-listed"; 1122 description 1123 "Specifies which of the NETCONF server's endpoints 1124 the NETCONF client should start with when trying 1125 to connect to the NETCONF server."; 1126 } 1127 leaf max-attempts { 1128 type uint8 { 1129 range "1..max"; 1130 } 1131 default "3"; 1132 description 1133 "Specifies the number times the NETCONF client tries 1134 to connect to a specific endpoint before moving on 1135 to the next endpoint in the list (round robin)."; 1136 } 1137 } 1138 } // netconf-server 1139 } // initiate 1141 container listen { 1142 if-feature "ssh-listen or tls-listen"; 1143 presence 1144 "Indicates that client-listening ports have been configured. 1145 This statement is present so the mandatory descendant nodes 1146 do not imply that this node must be configured."; 1147 description 1148 "Configures the client to accept call-home TCP connections."; 1149 leaf idle-timeout { 1150 type uint16; 1151 units "seconds"; 1152 default "3600"; // one hour 1153 description 1154 "Specifies the maximum number of seconds that a NETCONF 1155 session may remain idle. A NETCONF session will be 1156 dropped if it is idle for an interval longer than this 1157 number of seconds. If set to zero, then the server 1158 will never drop a session because it is idle. Sessions 1159 that have a notification subscription active are never 1160 dropped."; 1161 } 1162 list endpoint { 1163 key "name"; 1164 min-elements 1; 1165 description 1166 "List of endpoints to listen for NETCONF connections."; 1167 leaf name { 1168 type string; 1169 description 1170 "An arbitrary name for the NETCONF listen endpoint."; 1171 } 1172 uses netconf-client-listen-stack-grouping; 1173 } // endpoint 1174 } // listen 1175 } // netconf-client-app-grouping 1177 // Protocol accessible node for clients that implement this module. 1178 container netconf-client { 1179 uses netconf-client-app-grouping; 1180 description 1181 "Top-level container for NETCONF client configuration."; 1182 } 1183 } 1185 1187 3. The "ietf-netconf-server" Module 1189 The NETCONF server model presented in this section supports both 1190 listening for connections as well as initiating call-home 1191 connections, using either the SSH and TLS transport protocols. 1193 YANG feature statements are used to enable implementations to 1194 advertise which potentially uncommon parts of the model the NETCONF 1195 server supports. 1197 3.1. Data Model Overview 1199 This section provides an overview of the "ietf-netconf-server" module 1200 in terms of its features and groupings. 1202 3.1.1. Features 1204 The following diagram lists all the "feature" statements defined in 1205 the "ietf-netconf-server" module: 1207 Features: 1208 +-- ssh-listen 1209 +-- tls-listen 1210 +-- ssh-call-home 1211 +-- tls-call-home 1213 | The diagram above uses syntax that is similar to but not 1214 | defined in [RFC8340]. 1216 3.1.2. Groupings 1218 The "ietf-netconf-server" module defines the following "grouping" 1219 statements: 1221 * netconf-server-grouping 1222 * netconf-server-listen-stack-grouping 1223 * netconf-server-callhome-stack-grouping 1224 * netconf-server-app-grouping 1226 Each of these groupings are presented in the following subsections. 1228 3.1.2.1. The "netconf-server-grouping" Grouping 1230 The following tree diagram [RFC8340] illustrates the "netconf-server- 1231 grouping" grouping: 1233 grouping netconf-server-grouping 1234 +-- client-identity-mappings 1235 +---u x509c2n:cert-to-name 1237 Comments: 1239 * The "netconf-server-grouping" defines the configuration for just 1240 "NETCONF" part of a protocol stack. It does not, for instance, 1241 define any configuration for the "TCP", "SSH" or "TLS" protocol 1242 layers (for that, see Section 3.1.2.2 and Section 3.1.2.3). 1244 * The "client-identity-mappings" node, which must be enabled by 1245 "feature" statements, defines a mapping from certificate fields to 1246 NETCONF user names. 1248 * For the referenced grouping statement(s): 1250 - The "cert-to-name" grouping is discussed in Section 4.1 of 1251 [RFC7407]. 1253 3.1.2.2. The "netconf-server-listen-stack-grouping" Grouping 1255 The following tree diagram [RFC8340] illustrates the "netconf-server- 1256 listen-stack-grouping" grouping: 1258 grouping netconf-server-listen-stack-grouping 1259 +-- (transport) 1260 +--:(ssh) {ssh-listen}? 1261 | +-- ssh 1262 | +-- tcp-server-parameters 1263 | | +---u tcps:tcp-server-grouping 1264 | +-- ssh-server-parameters 1265 | | +---u sshs:ssh-server-grouping 1266 | +-- netconf-server-parameters 1267 | +---u ncs:netconf-server-grouping 1268 +--:(tls) {tls-listen}? 1269 +-- tls 1270 +-- tcp-server-parameters 1271 | +---u tcps:tcp-server-grouping 1272 +-- tls-server-parameters 1273 | +---u tlss:tls-server-grouping 1274 +-- netconf-server-parameters 1275 +---u ncs:netconf-server-grouping 1277 Comments: 1279 * The "netconf-server-listen-stack-grouping" defines the 1280 configuration for a full NETCONF protocol stack for NETCONF 1281 servers that listen for standard connections from NETCONF clients, 1282 as opposed to initiating call-home [RFC8071] connections. 1284 * The "transport" choice node enables both the SSH and TLS 1285 transports to be configured, with each option enabled by a 1286 "feature" statement. 1288 * For the referenced grouping statement(s): 1290 - The "tcp-server-grouping" grouping is discussed in 1291 Section 4.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 1292 - The "ssh-server-grouping" grouping is discussed in 1293 Section 4.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 1294 - The "tls-server-grouping" grouping is discussed in 1295 Section 4.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 1296 - The "netconf-server-grouping" is discussed in Section 3.1.2.1 1297 of this document. 1299 3.1.2.3. The "netconf-server-callhome-stack-grouping" Grouping 1301 The following tree diagram [RFC8340] illustrates the "netconf-server- 1302 callhome-stack-grouping" grouping: 1304 grouping netconf-server-callhome-stack-grouping 1305 +-- (transport) 1306 +--:(ssh) {ssh-call-home}? 1307 | +-- ssh 1308 | +-- tcp-client-parameters 1309 | | +---u tcpc:tcp-client-grouping 1310 | +-- ssh-server-parameters 1311 | | +---u sshs:ssh-server-grouping 1312 | +-- netconf-server-parameters 1313 | +---u ncs:netconf-server-grouping 1314 +--:(tls) {tls-call-home}? 1315 +-- tls 1316 +-- tcp-client-parameters 1317 | +---u tcpc:tcp-client-grouping 1318 +-- tls-server-parameters 1319 | +---u tlss:tls-server-grouping 1320 +-- netconf-server-parameters 1321 +---u ncs:netconf-server-grouping 1323 Comments: 1325 * The "netconf-server-callhome-stack-grouping" defines the 1326 configuration for a full NETCONF protocol stack, for NETCONF 1327 servers that initiate call-home [RFC8071] connections to NETCONF 1328 clients. 1330 * The "transport" choice node enables both the SSH and TLS 1331 transports to be configured, with each option enabled by a 1332 "feature" statement. 1334 * For the referenced grouping statement(s): 1336 - The "tcp-client-grouping" grouping is discussed in 1337 Section 3.1.2.1 of [I-D.ietf-netconf-tcp-client-server]. 1338 - The "ssh-server-grouping" grouping is discussed in 1339 Section 4.1.2.1 of [I-D.ietf-netconf-ssh-client-server]. 1340 - The "tls-server-grouping" grouping is discussed in 1341 Section 4.1.2.1 of [I-D.ietf-netconf-tls-client-server]. 1342 - The "netconf-server-grouping" is discussed in Section 3.1.2.1 1343 of this document. 1345 3.1.2.4. The "netconf-server-app-grouping" Grouping 1347 The following tree diagram [RFC8340] illustrates the "netconf-server- 1348 app-grouping" grouping: 1350 grouping netconf-server-app-grouping 1351 +-- listen! {ssh-listen or tls-listen}? 1352 | +-- idle-timeout? uint16 1353 | +-- endpoint* [name] 1354 | +-- name? string 1355 | +---u netconf-server-listen-stack-grouping 1356 +-- call-home! {ssh-call-home or tls-call-home}? 1357 +-- netconf-client* [name] 1358 +-- name? string 1359 +-- endpoints 1360 | +-- endpoint* [name] 1361 | +-- name? string 1362 | +---u netconf-server-callhome-stack-grouping 1363 +-- connection-type 1364 | +-- (connection-type) 1365 | +--:(persistent-connection) 1366 | | +-- persistent! 1367 | +--:(periodic-connection) 1368 | +-- periodic! 1369 | +-- period? uint16 1370 | +-- anchor-time? yang:date-and-time 1371 | +-- idle-timeout? uint16 1372 +-- reconnect-strategy 1373 +-- start-with? enumeration 1374 +-- max-attempts? uint8 1376 Comments: 1378 * The "netconf-server-app-grouping" defines the configuration for a 1379 NETCONF server that supports both listening for connections from 1380 NETCONF clients as well as initiating call-home connections to 1381 NETCONF clients. 1383 * Both the "listen" and "call-home" subtrees must be enabled by 1384 "feature" statements. 1386 * For the referenced grouping statement(s): 1388 - The "netconf-server-listen-stack-grouping" grouping is 1389 discussed in Section 3.1.2.2 in this document. 1390 - The "netconf-server-callhome-stack-grouping" grouping is 1391 discussed in Section 3.1.2.3 in this document. 1393 3.1.3. Protocol-accessible Nodes 1395 The following tree diagram [RFC8340] lists all the protocol- 1396 accessible nodes defined in the "ietf-netconf-server" module: 1398 module: ietf-netconf-server 1399 +--rw netconf-server 1400 +---u netconf-server-app-grouping 1402 | The diagram above uses syntax that is similar to but not 1403 | defined in [RFC8340]. 1405 Comments: 1407 * Protocol-accessible nodes are those nodes that are accessible when 1408 the module is "implemented", as described in Section 5.6.5 of 1409 [RFC7950]. 1411 * For the "ietf-netconf-server" module, the protocol-accessible 1412 nodes are an instance of the "netconf-server-app-grouping" 1413 discussed in Section 3.1.2.4 grouping. 1415 * The reason for why "netconf-server-app-grouping" exists separate 1416 from the protocol-accessible nodes definition is so as to enable 1417 instances of netconf-server-app-grouping to be instantiated in 1418 other locations, as may be needed or desired by some modules. 1420 3.2. Example Usage 1422 The following example illustrates configuring a NETCONF server to 1423 listen for NETCONF client connections using both the SSH and TLS 1424 transport protocols, as well as configuring call-home to two NETCONF 1425 clients, one using SSH and the other using TLS. 1427 This example is consistent with the examples presented in Section 2.2 1428 of [I-D.ietf-netconf-trust-anchors] and Section 2.2 of 1429 [I-D.ietf-netconf-keystore]. 1431 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1433 1436 1437 1438 1439 netconf/ssh 1440 1441 1442 192.0.2.7 1443 1444 1445 1446 1447 deployment-specific-certificate 1448 1449 ssh-rsa-key 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 netconf/tls 1463 1464 1465 192.0.2.7 1466 1467 1468 1469 1470 1471 rsa-asymmetric-key 1472 ex-rsa-cert 1473 1474 1475 1476 1477 1478 trusted-client-ca-certs 1480 1481 1482 trusted-client-ee-certs 1484 1485 1486 1487 1488 1490 1491 1492 1493 1494 1 1495 11:0A:05:11:00 1496 x509c2n:specified 1497 scooby-doo 1498 1499 1500 2 1501 x509c2n:san-any 1502 1503 1504 1505 1506 1507 1509 1510 1511 1512 config-mgr 1513 1514 1515 east-data-center 1516 1517 1518 east.config-mgr.example.com 1520 1521 15 1522 3 1523 30 1524 1525 1526 1527 1528 1529 deployment-specific-certificate 1530 1531 ssh-rsa-key 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 300 1569 60 1570 1571 1572 1573 last-connected 1574 3 1575 1576 1577 1578 data-collector 1579 1580 1581 east-data-center 1582 1583 1584 east.analytics.example.com 1586 1587 15 1588 3 1589 30 1590 1591 1592 1593 1594 1595 1596 rsa-asymmetric-key 1598 ex-rsa-cert 1599 1600 1601 1602 1603 1604 trusted-client-ca-certs 1606 1607 1608 trusted-client-ee-certs 1610 1611 1612 1613 1614 30 1615 3 1616 1617 1618 1619 1620 1621 1622 1 1623 11:0A:05:11:00 1624 x509c2n:specified 1625 scooby-doo 1626 1627 1628 2 1629 x509c2n:san-any 1630 1631 1632 1633 1635 1636 1637 west-data-center 1638 1639 1640 west.analytics.example.com 1642 1643 15 1644 3 1645 30 1646 1647 1648 1649 1650 1651 1652 rsa-asymmetric-key 1654 ex-rsa-cert 1655 1656 1657 1658 1659 1660 trusted-client-ca-certs 1662 1663 1664 trusted-client-ee-certs 1666 1667 1668 1669 1670 30 1671 3 1672 1673 1674 1675 1676 1677 1678 1 1679 11:0A:05:11:00 1680 x509c2n:specified 1681 scooby-doo 1682 1683 1684 2 1685 x509c2n:san-any 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 first-listed 1697 3 1698 1699 1700 1701 1703 3.3. YANG Module 1705 This YANG module has normative references to [RFC6242], [RFC6991], 1706 [RFC7407], [RFC7589], [RFC8071], 1707 [I-D.ietf-netconf-tcp-client-server], 1708 [I-D.ietf-netconf-ssh-client-server], and 1709 [I-D.ietf-netconf-tls-client-server]. 1711 file "ietf-netconf-server@2022-03-07.yang" 1713 module ietf-netconf-server { 1714 yang-version 1.1; 1715 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server"; 1716 prefix ncs; 1718 import ietf-yang-types { 1719 prefix yang; 1720 reference 1721 "RFC 6991: Common YANG Data Types"; 1722 } 1724 import ietf-x509-cert-to-name { 1725 prefix x509c2n; 1726 reference 1727 "RFC 7407: A YANG Data Model for SNMP Configuration"; 1728 } 1730 import ietf-tcp-client { 1731 prefix tcpc; 1732 reference 1733 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1734 } 1736 import ietf-tcp-server { 1737 prefix tcps; 1738 reference 1739 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1740 } 1742 import ietf-ssh-common { 1743 prefix sshcmn; 1744 revision-date 2022-03-07; // stable grouping definitions 1745 reference 1746 "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers"; 1747 } 1749 import ietf-ssh-server { 1750 prefix sshs; 1751 revision-date 2022-03-07; // stable grouping definitions 1752 reference 1753 "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers"; 1754 } 1756 import ietf-tls-server { 1757 prefix tlss; 1758 revision-date 2022-03-07; // stable grouping definitions 1759 reference 1760 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers"; 1761 } 1763 organization 1764 "IETF NETCONF (Network Configuration) Working Group"; 1766 contact 1767 "WG Web: https://datatracker.ietf.org/wg/netconf 1768 WG List: NETCONF WG list 1769 Author: Kent Watsen 1770 Author: Gary Wu 1771 Author: Juergen Schoenwaelder 1772 "; 1774 description 1775 "This module contains a collection of YANG definitions 1776 for configuring NETCONF servers. 1778 Copyright (c) 2021 IETF Trust and the persons identified 1779 as authors of the code. All rights reserved. 1781 Redistribution and use in source and binary forms, with 1782 or without modification, is permitted pursuant to, and 1783 subject to the license terms contained in, the Revised 1784 BSD License set forth in Section 4.c of the IETF Trust's 1785 Legal Provisions Relating to IETF Documents 1786 (https://trustee.ietf.org/license-info). 1788 This version of this YANG module is part of RFC HHHH 1789 (https://www.rfc-editor.org/info/rfcHHHH); see the RFC 1790 itself for full legal notices. 1792 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1793 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1794 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1795 are to be interpreted as described in BCP 14 (RFC 2119) 1796 (RFC 8174) when, and only when, they appear in all 1797 capitals, as shown here."; 1799 revision 2022-03-07 { 1800 description 1801 "Initial version"; 1802 reference 1803 "RFC HHHH: NETCONF Client and Server Models"; 1804 } 1806 // Features 1808 feature ssh-listen { 1809 description 1810 "The 'ssh-listen' feature indicates that the NETCONF server 1811 supports opening a port to accept NETCONF over SSH 1812 client connections."; 1813 reference 1814 "RFC 6242: 1815 Using the NETCONF Protocol over Secure Shell (SSH)"; 1816 } 1818 feature tls-listen { 1819 description 1820 "The 'tls-listen' feature indicates that the NETCONF server 1821 supports opening a port to accept NETCONF over TLS 1822 client connections."; 1823 reference 1824 "RFC 7589: Using the NETCONF Protocol over Transport 1825 Layer Security (TLS) with Mutual X.509 1826 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 descendant 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 description 1867 "Specifies mappings through which NETCONF client X.509 1868 certificates are used to determine a NETCONF username, 1869 per RFC 7407. 1871 For TLS-based transports, if no matching and valid 1872 cert-to-name list entry can be found, then the NETCONF 1873 server MUST close the connection, and MUST NOT accept 1874 NETCONF messages over it, per Section 7 in RFC 7589. 1876 For SSH-based transports, a matching cert-to-name 1877 entry overrides the username provided by the SSH 1878 implementation, consistent with the second paragraph 1879 of Section 3 in RFC 6242."; 1880 reference 1881 "RFC 6242: 1882 Using the NETCONF Protocol over Secure Shell (SSH) 1883 RFC 7589: 1884 Using the NETCONF Protocol over Transport Layer 1885 Security (TLS) with Mutual X.509 Authentication"; 1886 uses x509c2n:cert-to-name { 1887 refine "cert-to-name/fingerprint" { 1888 mandatory false; 1889 description 1890 "A 'fingerprint' value does not need to be specified 1891 when the 'cert-to-name' mapping is independent of 1892 fingerprint matching. A 'cert-to-name' having no 1893 fingerprint value will match any client certificate 1894 and therefore should only be present at the end of 1895 the user-ordered 'cert-to-name' list."; 1896 } 1897 } 1898 } 1899 } 1901 grouping netconf-server-listen-stack-grouping { 1902 description 1903 "A reusable grouping for configuring a NETCONF server 1904 'listen' protocol stack for a single connection."; 1905 choice transport { 1906 mandatory true; 1907 description 1908 "Selects between available transports."; 1909 case ssh { 1910 if-feature "ssh-listen"; 1911 container ssh { 1912 description 1913 "SSH-specific listening configuration for inbound 1914 connections."; 1915 container tcp-server-parameters { 1916 description 1917 "A wrapper around the TCP client parameters 1918 to avoid name collisions."; 1919 uses tcps:tcp-server-grouping { 1920 refine "local-port" { 1921 default "830"; 1922 description 1923 "The NETCONF server will listen on the 1924 IANA-assigned well-known port value 1925 for 'netconf-ssh' (830) if no value 1926 is specified."; 1927 } 1928 } 1929 } 1930 container ssh-server-parameters { 1931 description 1932 "A wrapper around the SSH server parameters 1933 to avoid name collisions."; 1934 uses sshs:ssh-server-grouping; 1935 } 1936 container netconf-server-parameters { 1937 description 1938 "A wrapper around the NETCONF server parameters 1939 to avoid name collisions."; 1940 uses ncs:netconf-server-grouping { 1941 refine "client-identity-mappings" { 1942 if-feature "sshcmn:ssh-x509-certs"; 1943 description 1944 "Augments in an 'if-feature' statement 1945 ensuring the 'client-identity-mappings' 1946 descendant is enabled only when SSH 1947 supports X.509 certificates."; 1948 } 1949 augment "client-identity-mappings" { 1950 description 1951 "Adds a flag indicating if a cert-to-name 1952 is required."; 1953 leaf mapping-required { 1954 type boolean; 1955 description 1956 "Indicates that the cert-to-name mapping 1957 is required (i.e., the SSH-level username 1958 is ignored)."; 1959 } 1960 } 1961 } 1962 } 1963 } 1964 } 1965 case tls { 1966 if-feature "tls-listen"; 1967 container tls { 1968 description 1969 "TLS-specific listening configuration for inbound 1970 connections."; 1971 container tcp-server-parameters { 1972 description 1973 "A wrapper around the TCP client parameters 1974 to avoid name collisions."; 1975 uses tcps:tcp-server-grouping { 1976 refine "local-port" { 1977 default "6513"; 1978 description 1979 "The NETCONF server will listen on the 1980 IANA-assigned well-known port value 1981 for 'netconf-tls' (6513) if no value 1982 is specified."; 1983 } 1984 } 1985 } 1986 container tls-server-parameters { 1987 description 1988 "A wrapper around the TLS server parameters to 1989 avoid name collisions."; 1990 uses tlss:tls-server-grouping { 1991 refine "client-authentication" { 1992 must 'ca-certs or ee-certs'; 1993 description 1994 "NETCONF/TLS servers MUST validate client 1995 certificates. This configures certificates 1996 at the socket-level (i.e. bags), more 1997 discriminating client-certificate checks 1998 SHOULD be implemented by the application."; 1999 reference 2000 "RFC 7589: 2001 Using the NETCONF Protocol over Transport Layer 2002 Security (TLS) with Mutual X.509 Authentication"; 2003 } 2004 } 2005 } 2006 container netconf-server-parameters { 2007 description 2008 "A wrapper around the NETCONF server parameters 2009 to avoid name collisions."; 2010 uses ncs:netconf-server-grouping { 2011 refine "client-identity-mappings/cert-to-name" { 2012 min-elements 1; 2013 description 2014 "The TLS transport requires a mapping."; 2015 } 2016 } 2017 } 2018 } 2019 } 2021 } 2022 } 2024 grouping netconf-server-callhome-stack-grouping { 2025 description 2026 "A reusable grouping for configuring a NETCONF server 2027 'call-home' protocol stack, for a single connection."; 2028 choice transport { 2029 mandatory true; 2030 description 2031 "Selects between available transports."; 2032 case ssh { 2033 if-feature "ssh-call-home"; 2034 container ssh { 2035 description 2036 "Specifies SSH-specific call-home transport 2037 configuration."; 2038 container tcp-client-parameters { 2039 description 2040 "A wrapper around the TCP client parameters 2041 to avoid name collisions."; 2042 uses tcpc:tcp-client-grouping { 2043 refine "remote-port" { 2044 default "4334"; 2045 description 2046 "The NETCONF server will attempt to connect 2047 to the IANA-assigned well-known port for 2048 'netconf-ch-tls' (4334) if no value is 2049 specified."; 2050 } 2051 } 2052 } 2053 container ssh-server-parameters { 2054 description 2055 "A wrapper around the SSH server parameters 2056 to avoid name collisions."; 2057 uses sshs:ssh-server-grouping; 2058 } 2059 container netconf-server-parameters { 2060 description 2061 "A wrapper around the NETCONF server parameters 2062 to avoid name collisions."; 2063 uses ncs:netconf-server-grouping { 2064 refine "client-identity-mappings" { 2065 if-feature "sshcmn:ssh-x509-certs"; 2066 description 2067 "Augments in an 'if-feature' statement 2068 ensuring the 'client-identity-mappings' 2069 descendant is enabled only when SSH 2070 supports X.509 certificates."; 2071 } 2072 augment "client-identity-mappings" { 2073 description 2074 "Adds a flag indicating if a cert-to-name 2075 is required."; 2076 leaf mapping-required { 2077 type boolean; 2078 description 2079 "Indicates that the cert-to-name mapping 2080 is required (i.e., the SSH-level username 2081 is ignored)."; 2082 } 2083 } 2084 } 2085 } 2086 } 2087 } 2088 case tls { 2089 if-feature "tls-call-home"; 2090 container tls { 2091 description 2092 "Specifies TLS-specific call-home transport 2093 configuration."; 2094 container tcp-client-parameters { 2095 description 2096 "A wrapper around the TCP client parameters 2097 to avoid name collisions."; 2098 uses tcpc:tcp-client-grouping { 2099 refine "remote-port" { 2100 default "4335"; 2101 description 2102 "The NETCONF server will attempt to connect 2103 to the IANA-assigned well-known port for 2104 'netconf-ch-tls' (4335) if no value is 2105 specified."; 2106 } 2107 } 2108 } 2109 container tls-server-parameters { 2110 description 2111 "A wrapper around the TLS server parameters to 2112 avoid name collisions."; 2113 uses tlss:tls-server-grouping { 2114 refine "client-authentication" { 2115 must 'ca-certs or ee-certs'; 2116 description 2117 "NETCONF/TLS servers MUST validate client 2118 certificates. This configures certificates 2119 at the socket-level (i.e. bags), more 2120 discriminating client-certificate checks 2121 SHOULD be implemented by the application."; 2122 reference 2123 "RFC 7589: 2124 Using the NETCONF Protocol over Transport Layer 2125 Security (TLS) with Mutual X.509 Authentication"; 2126 } 2127 } 2128 } 2129 container netconf-server-parameters { 2130 description 2131 "A wrapper around the NETCONF server parameters 2132 to avoid name collisions."; 2133 uses ncs:netconf-server-grouping { 2134 refine "client-identity-mappings/cert-to-name" { 2135 min-elements 1; 2136 description 2137 "The TLS transport requires a mapping."; 2138 } 2139 } 2140 } 2141 } 2142 } 2143 } 2144 } 2146 grouping netconf-server-app-grouping { 2147 description 2148 "A reusable grouping for configuring a NETCONF server 2149 application that supports both 'listen' and 'call-home' 2150 protocol stacks for a multiplicity of connections."; 2151 container listen { 2152 if-feature "ssh-listen or tls-listen"; 2153 presence 2154 "Indicates that server-listening ports have been configured. 2155 This statement is present so the mandatory descendant 2156 nodes do not imply that this node must be configured."; 2157 description 2158 "Configures listen behavior"; 2159 leaf idle-timeout { 2160 type uint16; 2161 units "seconds"; 2162 default "3600"; // one hour 2163 description 2164 "Specifies the maximum number of seconds that a NETCONF 2165 session may remain idle. A NETCONF session will be 2166 dropped if it is idle for an interval longer than this 2167 number of seconds. If set to zero, then the server 2168 will never drop a session because it is idle. Sessions 2169 that have a notification subscription active are never 2170 dropped."; 2171 } 2172 list endpoint { 2173 key "name"; 2174 min-elements 1; 2175 description 2176 "List of endpoints to listen for NETCONF connections."; 2177 leaf name { 2178 type string; 2179 description 2180 "An arbitrary name for the NETCONF listen endpoint."; 2181 } 2182 uses netconf-server-listen-stack-grouping; 2183 } 2184 } 2185 container call-home { 2186 if-feature "ssh-call-home or tls-call-home"; 2187 presence 2188 "Indicates that server-initiated call home connections have 2189 been configured. This statement is present so the mandatory 2190 descendant nodes do not imply that this node must be 2191 configured."; 2192 description 2193 "Configures the NETCONF server to initiate the underlying 2194 transport connection to NETCONF clients."; 2195 list netconf-client { 2196 key "name"; 2197 min-elements 1; 2198 description 2199 "List of NETCONF clients the NETCONF server is to 2200 maintain simultaneous call-home connections with."; 2201 leaf name { 2202 type string; 2203 description 2204 "An arbitrary name for the remote NETCONF client."; 2205 } 2206 container endpoints { 2207 description 2208 "Container for the list of endpoints."; 2209 list endpoint { 2210 key "name"; 2211 min-elements 1; 2212 ordered-by user; 2213 description 2214 "A non-empty user-ordered list of endpoints for this 2215 NETCONF server to try to connect to in sequence. 2216 Defining more than one enables high-availability."; 2217 leaf name { 2218 type string; 2219 description 2220 "An arbitrary name for this endpoint."; 2221 } 2222 uses netconf-server-callhome-stack-grouping; 2223 } 2224 } 2225 container connection-type { 2226 description 2227 "Indicates the NETCONF server's preference for how the 2228 NETCONF connection is maintained."; 2229 choice connection-type { 2230 mandatory true; 2231 description 2232 "Selects between available connection types."; 2233 case persistent-connection { 2234 container persistent { 2235 presence 2236 "Indicates that a persistent connection is to be 2237 maintained."; 2238 description 2239 "Maintain a persistent connection to the NETCONF 2240 client. If the connection goes down, immediately 2241 start trying to reconnect to the NETCONF client, 2242 using the reconnection strategy. 2244 This connection type minimizes any NETCONF client 2245 to NETCONF server data-transfer delay, albeit at 2246 the expense of holding resources longer."; 2247 } 2248 } 2249 case periodic-connection { 2250 container periodic { 2251 presence "Indicates that a periodic connection is 2252 to be maintained."; 2253 description 2254 "Periodically connect to the NETCONF client. 2256 This connection type increases resource 2257 utilization, albeit with increased delay in 2258 NETCONF client to NETCONF client interactions. 2260 The NETCONF client SHOULD gracefully close the 2261 connection using upon completing 2262 planned activities. If the NETCONF session is 2263 not closed gracefully, the NETCONF server MUST 2264 immediately attempt to reestablish the connection. 2266 In the case that the previous connection is still 2267 active (i.e., the NETCONF client has not closed 2268 it yet), establishing a new connection is NOT 2269 RECOMMENDED."; 2270 leaf period { 2271 type uint16; 2272 units "minutes"; 2273 default "60"; 2274 description 2275 "Duration of time between periodic connections."; 2276 } 2277 leaf anchor-time { 2278 type yang:date-and-time { 2279 // constrained to minute-level granularity 2280 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}' 2281 + '(Z|[\+\-]\d{2}:\d{2})'; 2282 } 2283 description 2284 "Designates a timestamp before or after which a 2285 series of periodic connections are determined. 2286 The periodic connections occur at a whole 2287 multiple interval from the anchor time. For 2288 example, for an anchor time is 15 minutes past 2289 midnight and a period interval of 24 hours, then 2290 a periodic connection will occur 15 minutes past 2291 midnight everyday."; 2292 } 2293 leaf idle-timeout { 2294 type uint16; 2295 units "seconds"; 2296 default "120"; // two minutes 2297 description 2298 "Specifies the maximum number of seconds that 2299 a NETCONF session may remain idle. A NETCONF 2300 session will be dropped if it is idle for an 2301 interval longer than this number of seconds. 2302 If set to zero, then the server will never 2303 drop a session because it is idle."; 2304 } 2305 } 2306 } // case periodic-connection 2307 } // choice connection-type 2308 } // container connection-type 2309 container reconnect-strategy { 2310 description 2311 "The reconnection strategy directs how a NETCONF server 2312 reconnects to a NETCONF client, after discovering its 2313 connection to the client has dropped, even if due to a 2314 reboot. The NETCONF server starts with the specified 2315 endpoint and tries to connect to it max-attempts times 2316 before trying the next endpoint in the list (round 2317 robin)."; 2318 leaf start-with { 2319 type enumeration { 2320 enum first-listed { 2321 description 2322 "Indicates that reconnections should start with 2323 the first endpoint listed."; 2324 } 2325 enum last-connected { 2326 description 2327 "Indicates that reconnections should start with 2328 the endpoint last connected to. If no previous 2329 connection has ever been established, then the 2330 first endpoint configured is used. NETCONF 2331 servers SHOULD be able to remember the last 2332 endpoint connected to across reboots."; 2333 } 2334 enum random-selection { 2335 description 2336 "Indicates that reconnections should start with 2337 a random endpoint."; 2338 } 2339 } 2340 default "first-listed"; 2341 description 2342 "Specifies which of the NETCONF client's endpoints 2343 the NETCONF server should start with when trying 2344 to connect to the NETCONF client."; 2345 } 2346 leaf max-attempts { 2347 type uint8 { 2348 range "1..max"; 2349 } 2350 default "3"; 2351 description 2352 "Specifies the number times the NETCONF server tries 2353 to connect to a specific endpoint before moving on 2354 to the next endpoint in the list (round robin)."; 2355 } 2356 } // container reconnect-strategy 2358 } // list netconf-client 2359 } // container call-home 2360 } // grouping netconf-server-app-grouping 2362 // Protocol accessible node for servers that implement this module. 2363 container netconf-server { 2364 uses netconf-server-app-grouping; 2365 description 2366 "Top-level container for NETCONF server configuration."; 2367 } 2368 } 2370 2372 4. Security Considerations 2374 4.1. The "ietf-netconf-client" YANG Module 2376 The "ietf-netconf-client" YANG module defines data nodes that are 2377 designed to be accessed via YANG based management protocols, such as 2378 NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 2379 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 2380 with mutual authentication. 2382 The NETCONF access control model (NACM) [RFC8341] provides the means 2383 to restrict access for particular users to a pre-configured subset of 2384 all available protocol operations and content. 2386 None of the readable data nodes defined in this YANG module are 2387 considered sensitive or vulnerable in network environments. The NACM 2388 "default-deny-all" extension has not been set for any data nodes 2389 defined in this module. 2391 None of the writable data nodes defined in this YANG module are 2392 considered sensitive or vulnerable in network environments. The NACM 2393 "default-deny-write" extension has not been set for any data nodes 2394 defined in this module. 2396 This module does not define any RPCs, actions, or notifications, and 2397 thus the security consideration for such is not provided here. 2399 Please be aware that this module uses groupings defined in other RFCs 2400 that define data nodes that do set the NACM "default-deny-all" and 2401 "default-deny-write" extensions. 2403 4.2. The "ietf-netconf-server" YANG Module 2405 The "ietf-netconf-server" YANG module defines data nodes that are 2406 designed to be accessed via YANG based management protocols, such as 2407 NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 2408 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 2409 with mutual authentication. 2411 The NETCONF access control model (NACM) [RFC8341] provides the means 2412 to restrict access for particular users to a pre-configured subset of 2413 all available protocol operations and content. 2415 None of the readable data nodes defined in this YANG module are 2416 considered sensitive or vulnerable in network environments. The NACM 2417 "default-deny-all" extension has not been set for any data nodes 2418 defined in this module. 2420 None of the writable data nodes defined in this YANG module are 2421 considered sensitive or vulnerable in network environments. The NACM 2422 "default-deny-write" extension has not been set for any data nodes 2423 defined in this module. 2425 This module does not define any RPCs, actions, or notifications, and 2426 thus the security consideration for such is not provided here. 2428 Please be aware that this module uses groupings defined in other RFCs 2429 that define data nodes that do set the NACM "default-deny-all" and 2430 "default-deny-write" extensions. 2432 5. IANA Considerations 2434 5.1. The "IETF XML" Registry 2436 This document registers two URIs in the "ns" subregistry of the IETF 2437 XML Registry [RFC3688]. Following the format in [RFC3688], the 2438 following registrations are requested: 2440 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-client 2441 Registrant Contact: The IESG 2442 XML: N/A, the requested URI is an XML namespace. 2444 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server 2445 Registrant Contact: The IESG 2446 XML: N/A, the requested URI is an XML namespace. 2448 5.2. The "YANG Module Names" Registry 2450 This document registers two YANG modules in the YANG Module Names 2451 registry [RFC6020]. Following the format in [RFC6020], the following 2452 registrations are requested: 2454 name: ietf-netconf-client 2455 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-client 2456 prefix: ncc 2457 reference: RFC HHHH 2459 name: ietf-netconf-server 2460 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server 2461 prefix: ncs 2462 reference: RFC HHHH 2464 6. References 2466 6.1. Normative References 2468 [I-D.ietf-netconf-keystore] 2469 Watsen, K., "A YANG Data Model for a Keystore", Work in 2470 Progress, Internet-Draft, draft-ietf-netconf-keystore-23, 2471 14 December 2021, . 2474 [I-D.ietf-netconf-ssh-client-server] 2475 Watsen, K., "YANG Groupings for SSH Clients and SSH 2476 Servers", Work in Progress, Internet-Draft, draft-ietf- 2477 netconf-ssh-client-server-26, 14 December 2021, 2478 . 2481 [I-D.ietf-netconf-tcp-client-server] 2482 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 2483 and TCP Servers", Work in Progress, Internet-Draft, draft- 2484 ietf-netconf-tcp-client-server-11, 14 December 2021, 2485 . 2488 [I-D.ietf-netconf-tls-client-server] 2489 Watsen, K., "YANG Groupings for TLS Clients and TLS 2490 Servers", Work in Progress, Internet-Draft, draft-ietf- 2491 netconf-tls-client-server-26, 14 December 2021, 2492 . 2495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2496 Requirement Levels", BCP 14, RFC 2119, 2497 DOI 10.17487/RFC2119, March 1997, 2498 . 2500 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2501 the Network Configuration Protocol (NETCONF)", RFC 6020, 2502 DOI 10.17487/RFC6020, October 2010, 2503 . 2505 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2506 and A. Bierman, Ed., "Network Configuration Protocol 2507 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2508 . 2510 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2511 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2512 . 2514 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2515 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2516 . 2518 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 2519 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 2520 December 2014, . 2522 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2523 NETCONF Protocol over Transport Layer Security (TLS) with 2524 Mutual X.509 Authentication", RFC 7589, 2525 DOI 10.17487/RFC7589, June 2015, 2526 . 2528 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2529 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2530 . 2532 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2533 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2534 May 2017, . 2536 6.2. Informative References 2538 [I-D.ietf-netconf-crypto-types] 2539 Watsen, K., "YANG Data Types and Groupings for 2540 Cryptography", Work in Progress, Internet-Draft, draft- 2541 ietf-netconf-crypto-types-21, 14 September 2021, 2542 . 2545 [I-D.ietf-netconf-http-client-server] 2546 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 2547 Servers", Work in Progress, Internet-Draft, draft-ietf- 2548 netconf-http-client-server-08, 14 December 2021, 2549 . 2552 [I-D.ietf-netconf-netconf-client-server] 2553 Watsen, K., "NETCONF Client and Server Models", Work in 2554 Progress, Internet-Draft, draft-ietf-netconf-netconf- 2555 client-server-24, 14 December 2021, 2556 . 2559 [I-D.ietf-netconf-restconf-client-server] 2560 Watsen, K., "RESTCONF Client and Server Models", Work in 2561 Progress, Internet-Draft, draft-ietf-netconf-restconf- 2562 client-server-24, 14 December 2021, 2563 . 2566 [I-D.ietf-netconf-trust-anchors] 2567 Watsen, K., "A YANG Data Model for a Truststore", Work in 2568 Progress, Internet-Draft, draft-ietf-netconf-trust- 2569 anchors-16, 14 December 2021, 2570 . 2573 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2574 DOI 10.17487/RFC3688, January 2004, 2575 . 2577 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2578 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2579 . 2581 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 2582 RFC 8071, DOI 10.17487/RFC8071, February 2017, 2583 . 2585 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2586 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2587 . 2589 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2590 Access Control Model", STD 91, RFC 8341, 2591 DOI 10.17487/RFC8341, March 2018, 2592 . 2594 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2595 and R. Wilton, "Network Management Datastore Architecture 2596 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2597 . 2599 Appendix A. Change Log 2601 This section is to be removed before publishing as an RFC. 2603 A.1. 00 to 01 2605 * Renamed "keychain" to "keystore". 2607 A.2. 01 to 02 2609 * Added to ietf-netconf-client ability to connected to a cluster of 2610 endpoints, including a reconnection-strategy. 2612 * Added to ietf-netconf-client the ability to configure connection- 2613 type and also keep-alive strategy. 2615 * Updated both modules to accommodate new groupings in the ssh/tls 2616 drafts. 2618 A.3. 02 to 03 2620 * Refined use of tls-client-grouping to add a must statement 2621 indicating that the TLS client must specify a client-certificate. 2623 * Changed 'netconf-client' to be a grouping (not a container). 2625 A.4. 03 to 04 2627 * Added RFC 8174 to Requirements Language Section. 2629 * Replaced refine statement in ietf-netconf-client to add a 2630 mandatory true. 2632 * Added refine statement in ietf-netconf-server to add a must 2633 statement. 2635 * Now there are containers and groupings, for both the client and 2636 server models. 2638 A.5. 04 to 05 2640 * Now tree diagrams reference ietf-netmod-yang-tree-diagrams 2642 * Updated examples to inline key and certificates (no longer a 2643 leafref to keystore) 2645 A.6. 05 to 06 2647 * Fixed change log missing section issue. 2649 * Updated examples to match latest updates to the crypto-types, 2650 trust-anchors, and keystore drafts. 2652 * Reduced line length of the YANG modules to fit within 69 columns. 2654 A.7. 06 to 07 2656 * Removed "idle-timeout" from "persistent" connection config. 2658 * Added "random-selection" for reconnection-strategy's "starts-with" 2659 enum. 2661 * Replaced "connection-type" choice default (persistent) with 2662 "mandatory true". 2664 * Reduced the periodic-connection's "idle-timeout" from 5 to 2 2665 minutes. 2667 * Replaced reconnect-timeout with period/anchor-time combo. 2669 A.8. 07 to 08 2671 * Modified examples to be compatible with new crypto-types algs 2673 A.9. 08 to 09 2675 * Corrected use of "mandatory true" for "address" leafs. 2677 * Updated examples to reflect update to groupings defined in the 2678 keystore draft. 2680 * Updated to use groupings defined in new TCP and HTTP drafts. 2682 * Updated copyright date, boilerplate template, affiliation, and 2683 folding algorithm. 2685 A.10. 09 to 10 2687 * Reformatted YANG modules. 2689 A.11. 10 to 11 2691 * Adjusted for the top-level "demux container" added to groupings 2692 imported from other modules. 2694 * Added "must" expressions to ensure that keepalives are not 2695 configured for "periodic" connections. 2697 * Updated the boilerplate text in module-level "description" 2698 statement to match copyeditor convention. 2700 * Moved "expanded" tree diagrams to the Appendix. 2702 A.12. 11 to 12 2704 * Removed the "Design Considerations" section. 2706 * Removed the 'must' statement limiting keepalives in periodic 2707 connections. 2709 * Updated models and examples to reflect removal of the "demux" 2710 containers in the imported models. 2712 * Updated the "periodic-connnection" description statements to be 2713 more like the RESTCONF draft, especially where it described 2714 dropping the underlying TCP connection. 2716 * Updated text to better reference where certain examples come from 2717 (e.g., which Section in which draft). 2719 * In the server model, commented out the "must 'pinned-ca-certs or 2720 pinned-client-certs'" statement to reflect change made in the TLS 2721 draft whereby the trust anchors MAY be defined externally. 2723 * Replaced the 'listen', 'initiate', and 'call-home' features with 2724 boolean expressions. 2726 A.13. 12 to 13 2727 * Updated to reflect changes in trust-anchors drafts (e.g., s/trust- 2728 anchors/truststore/g + s/pinned.//) 2730 A.14. 13 to 14 2732 * Adjusting from change in TLS client model (removing the top-level 2733 'certificate' container), by swapping refining-in a 'mandatory 2734 true' statement with a 'must' statement outside the 'uses' 2735 statement. 2737 * Updated examples to reflect ietf-crypto-types change (e.g., 2738 identities --> enumerations) 2740 A.15. 14 to 15 2742 * Refactored both the client and server modules similar to how the 2743 ietf-restconf-server module was refactored in -13 of that draft, 2744 and the ietf-restconf-client grouping. 2746 A.16. 15 to 16 2748 * Added refinement to make "cert-to-name/fingerprint" be mandatory 2749 false. 2751 * Commented out refinement to "tls-server-grouping/client- 2752 authentication" until a better "must" expression is defined. 2754 A.17. 16 to 17 2756 * Updated examples to include the "*-key-format" nodes. 2758 * Updated examples to remove the "required" nodes. 2760 * Updated examples to remove the "client-auth-defined-elsewhere" 2761 nodes. 2763 A.18. 17 to 18 2765 * Updated examples to reflect new "bag" addition to truststore. 2767 A.19. 18 to 19 2769 * Updated examples to remove the 'algorithm' nodes. 2771 * Updated examples to reflect the new TLS keepalives structure. 2773 * Added keepalives to the tcp-client-parameters section in the 2774 netconf-server SSH-based call-home example. 2776 * Added a TLS-based call-home example to the netconf-client example. 2778 * Added a "Note to Reviewers" note to first page. 2780 A.20. 19 to 20 2782 * Expanded "Data Model Overview section(s) [remove "wall" of tree 2783 diagrams]. 2785 * Removed expanded tree diagrams that were listed in the Appendix. 2787 * Updated the Security Considerations section. 2789 A.21. 20 to 21 2791 * Cleaned up titles in the IANA Considerations section 2793 * Fixed issues found by the SecDir review of the "keystore" draft. 2795 A.22. 21 to 22 2797 * Addressed comments raised by YANG Doctor in the ct/ts/ks drafts. 2799 A.23. 22 to 23 2801 * Floated an 'if-feature' statement in a grouping down to where the 2802 grouping is used. 2804 * Clarified 'client-identity-mappings' for both the SSH and TLS 2805 transports. 2807 * For netconf-client, augmented-in a 'mapping-required' flag into 2808 'client-identity-mappings' only for the SSH transport, and 2809 refined-in a 'min-elements 1' only for the TLS transport. 2811 * Aligned modules with `pyang -f` formatting. 2813 A.24. 23 to 24 2815 * Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples. 2817 * Minor editorial nits 2819 A.25. 24 to 25 2821 * Fixed up the 'WG Web' and 'WG List' lines in YANG module(s) 2823 * Fixed up copyright (i.e., s/Simplified/Revised/) in YANG module(s) 2825 Acknowledgements 2827 The authors would like to thank for following for lively discussions 2828 on list and in the halls (ordered by first name): Alan Luchuk, Andy 2829 Bierman, Balazs Kovacs, Benoit Claise, Bert Wijnen, David Lamparter, 2830 Juergen Schoenwaelder, Ladislav Lhotka, Martin Bjoerklund, Mehmet 2831 Ersue, Phil Shafer, Radek Krejci, Ramkumar Dhanapal, Sean Turner, and 2832 Tom Petch. 2834 Author's Address 2836 Kent Watsen 2837 Watsen Networks 2838 Email: kent+ietf@watsen.net