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