idnits 2.17.1 draft-ietf-netconf-restconf-client-server-07.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 (September 20, 2018) is 2038 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-06 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-06 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-06 Summary: 0 errors (**), 0 flaws (~~), 4 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 Juniper Networks 4 Intended status: Standards Track September 20, 2018 5 Expires: March 24, 2019 7 RESTCONF Client and Server Models 8 draft-ietf-netconf-restconf-client-server-07 10 Abstract 12 This document defines two YANG modules, one module to configure a 13 RESTCONF client and the other module to configure a RESTCONF server. 14 Both modules support the TLS transport protocol with both standard 15 RESTCONF and RESTCONF Call Home connections. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains many placeholder values that need to be replaced 20 with finalized values at the time of publication. This note 21 summarizes all of the substitutions that are needed. No other RFC 22 Editor instructions are specified elsewhere in this document. 24 This document contains references to other drafts in progress, both 25 in the Normative References section, as well as in body text 26 throughout. Please update the following references to reflect their 27 final RFC assignments: 29 o I-D.ietf-netconf-keystore 31 o I-D.ietf-netconf-tls-client-server 33 Artwork in this document contains shorthand references to drafts in 34 progress. Please apply the following replacements: 36 o "XXXX" --> the assigned RFC value for this draft 38 o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- 39 server 41 Artwork in this document contains placeholder values for the date of 42 publication of this draft. Please apply the following replacement: 44 o "2018-09-20" --> the publication date of this draft 46 The following Appendix section is to be removed prior to publication: 48 o Appendix A. Change Log 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at https://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on March 24, 2019. 67 Copyright Notice 69 Copyright (c) 2018 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (https://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 86 2. The RESTCONF Client Model . . . . . . . . . . . . . . . . . . 3 87 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 88 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7 89 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 90 3. The RESTCONF Server Model . . . . . . . . . . . . . . . . . . 18 91 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 18 92 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 21 93 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 94 4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 96 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 35 97 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 35 99 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 100 6.1. Normative References . . . . . . . . . . . . . . . . . . 36 101 6.2. Informative References . . . . . . . . . . . . . . . . . 37 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 38 103 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 38 104 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 38 105 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 38 106 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 38 107 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 38 108 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 39 109 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 39 110 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 113 1. Introduction 115 This document defines two YANG [RFC7950] modules, one module to 116 configure a RESTCONF client and the other module to configure a 117 RESTCONF server [RFC8040]. Both modules support the TLS [RFC8446] 118 transport protocol with both standard RESTCONF and RESTCONF Call Home 119 connections [RFC8071]. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2. The RESTCONF Client Model 131 The RESTCONF client model presented in this section supports both 132 clients initiating connections to servers, as well as clients 133 listening for connections from servers calling home. 135 This model, like that presented in 136 [I-D.ietf-netconf-netconf-client-server], is designed to support any 137 number of possible transports. RESTCONF only supports the TLS 138 transport currently, thus this model only supports the TLS transport. 140 All private keys and trusted certificates are held in the keystore 141 model defined in [I-D.ietf-netconf-keystore]. 143 YANG feature statements are used to enable implementations to 144 advertise which parts of the model the RESTCONF client supports. 146 2.1. Tree Diagram 148 The following tree diagram [RFC8340] provides an overview of the data 149 model for the "ietf-restconf-client" module. Just the container is 150 displayed below, but there is also a reusable grouping called 151 "restconf-client-grouping" that the container is using. 153 [Note: '\' line wrapping for formatting only] 155 module: ietf-restconf-client 156 +--rw restconf-client 157 +--rw initiate! {initiate}? 158 | +--rw restconf-server* [name] 159 | +--rw name string 160 | +--rw endpoints 161 | +--rw endpoint* [name] 162 | +--rw name string 163 | +--rw (transport) 164 | | +--:(tls) {tls-initiate}? 165 | | +--rw tls 166 | | +--rw address inet:host 167 | | +--rw port? inet:port-number 168 | | +--rw client-identity 169 | | | +--rw (auth-type) 170 | | | +--:(certificate) 171 | | | +--rw certificate 172 | | | +--rw (local-or-keystore) 173 | | | +--:(local) 174 | | | | {local-keys-suppor\ 175 ted}? 176 | | | | +--rw algorithm? 177 | | | | | ct:key-algorithm\ 178 -ref 179 | | | | +--rw public-key? 180 | | | | | binary 181 | | | | +--rw private-key? 182 | | | | | union 183 | | | | +---x generate-hidden-key 184 | | | | | +---w input 185 | | | | | +---w algorithm 186 | | | | | ct:key-alg\ 187 orithm-ref 188 | | | | +---x install-hidden-key 189 | | | | | +---w input 190 | | | | | +---w algorithm 191 | | | | | | ct:key-alg\ 192 orithm-ref 193 | | | | | +---w public-key? 194 | | | | | | binary 195 | | | | | +---w private-key? 196 | | | | | binary 197 | | | | +--rw cert 198 | | | | | ct:end-entity-ce\ 199 rt-cms 200 | | | | +---n certificate-expira\ 201 tion 202 | | | | +-- expiration-date? 203 | | | | yang:date-and\ 204 -time 205 | | | +--:(keystore) 206 | | | {keystore-supporte\ 207 d}? 208 | | | +--rw reference? 209 | | | ks:asymmetric-ke\ 210 y-certificate-ref 211 | | +--rw server-auth 212 | | | +--rw pinned-ca-certs? 213 | | | | ta:pinned-certificates-ref 214 | | | | {ta:x509-certificates}? 215 | | | +--rw pinned-server-certs? 216 | | | ta:pinned-certificates-ref 217 | | | {ta:x509-certificates}? 218 | | +--rw hello-params 219 | | {tls-client-hello-params-config}? 220 | | +--rw tls-versions 221 | | | +--rw tls-version* identityref 222 | | +--rw cipher-suites 223 | | +--rw cipher-suite* identityref 224 | +--rw connection-type 225 | | +--rw (connection-type) 226 | | +--:(persistent-connection) 227 | | | +--rw persistent! 228 | | | +--rw keep-alives 229 | | | +--rw max-wait? uint16 230 | | | +--rw max-attempts? uint8 231 | | +--:(periodic-connection) 232 | | +--rw periodic! 233 | | +--rw period? uint16 234 | | +--rw anchor-time? yang:date-and-time 235 | | +--rw idle-timeout? uint16 236 | +--rw reconnect-strategy 237 | +--rw start-with? enumeration 238 | +--rw max-attempts? uint8 239 +--rw listen! {listen}? 240 +--rw idle-timeout? uint16 241 +--rw endpoint* [name] 242 +--rw name string 243 +--rw (transport) 244 +--:(tls) {tls-listen}? 245 +--rw tls 246 +--rw address? inet:ip-address 247 +--rw port? inet:port-number 248 +--rw client-identity 249 | +--rw (auth-type) 250 | +--:(certificate) 251 | +--rw certificate 252 | +--rw (local-or-keystore) 253 | +--:(local) {local-keys-supported\ 254 }? 255 | | +--rw algorithm? 256 | | | ct:key-algorithm-ref 257 | | +--rw public-key? 258 | | | binary 259 | | +--rw private-key? 260 | | | union 261 | | +---x generate-hidden-key 262 | | | +---w input 263 | | | +---w algorithm 264 | | | ct:key-algorithm\ 265 -ref 266 | | +---x install-hidden-key 267 | | | +---w input 268 | | | +---w algorithm 269 | | | | ct:key-algorithm\ 270 -ref 271 | | | +---w public-key? bin\ 272 ary 273 | | | +---w private-key? bin\ 274 ary 275 | | +--rw cert 276 | | | ct:end-entity-cert-cms 277 | | +---n certificate-expiration 278 | | +-- expiration-date? 279 | | yang:date-and-time 280 | +--:(keystore) {keystore-supporte\ 281 d}? 282 | +--rw reference? 283 | ks:asymmetric-key-cert\ 284 ificate-ref 285 +--rw server-auth 286 | +--rw pinned-ca-certs? 287 | | ta:pinned-certificates-ref 288 | | {ta:x509-certificates}? 289 | +--rw pinned-server-certs? 290 | ta:pinned-certificates-ref 291 | {ta:x509-certificates}? 292 +--rw hello-params 293 {tls-client-hello-params-config}? 294 +--rw tls-versions 295 | +--rw tls-version* identityref 296 +--rw cipher-suites 297 +--rw cipher-suite* identityref 299 2.2. Example Usage 301 The following example illustrates configuring a RESTCONF client to 302 initiate connections, as well as listening for call-home connections. 304 This example is consistent with the examples presented in Section 3.2 305 of [I-D.ietf-netconf-keystore]. 307 [Note: '\' line wrapping for formatting only] 309 312 313 314 315 corp-fw1 316 317 318 corp-fw1.example.com 319 320
corp-fw1.example.com
321 322 323 ct:secp521r1 325 base64encodedvalue== 326 base64encodedvalue== 327 base64encodedvalue== 328 329 330 331 explicitly-trusted-server-ca-certs 333 explicitly-trusted-server-certs 335 337 338 339 340 341 342 343 corp-fw2.example.com 344 345
corp-fw2.example.com
346 347 348 ct:secp521r1 350 base64encodedvalue== 351 base64encodedvalue== 352 base64encodedvalue== 353 354 355 356 explicitly-trusted-server-ca-certs 358 explicitly-trusted-server-certs 360 361 362 363 364 365 366 367 368 370 371 372 373 Intranet-facing listener 374 375
11.22.33.44
376 377 378 ct:secp521r1 380 base64encodedvalue== 381 base64encodedvalue== 382 base64encodedvalue== 383 384 385 386 explicitly-trusted-server-ca-certs 388 explicitly-trusted-server-certs 390 391 392 393 394 396 2.3. YANG Module 398 This YANG module has normative references to [RFC6991], [RFC8040], 399 and [RFC8071], and [I-D.ietf-netconf-tls-client-server]. 401 file "ietf-restconf-client@2018-09-20.yang" 402 module ietf-restconf-client { 403 yang-version 1.1; 405 namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-client"; 406 prefix "rcc"; 408 import ietf-yang-types { 409 prefix yang; 410 reference 411 "RFC 6991: Common YANG Data Types"; 412 } 414 import ietf-inet-types { 415 prefix inet; 416 reference 417 "RFC 6991: Common YANG Data Types"; 418 } 420 import ietf-tls-client { 421 prefix ts; 422 revision-date 2018-09-20; // stable grouping definitions 423 reference 424 "RFC ZZZZ: YANG Groupings for TLS Clients and TLS Servers"; 425 } 427 organization 428 "IETF NETCONF (Network Configuration) Working Group"; 430 contact 431 "WG Web: 432 WG List: 433 Author: Kent Watsen 434 436 Author: Gary Wu 437 "; 439 description 440 "This module contains a collection of YANG definitions for 441 configuring RESTCONF clients. 443 Copyright (c) 2017 IETF Trust and the persons identified as 444 authors of the code. All rights reserved. 446 Redistribution and use in source and binary forms, with or 447 without modification, is permitted pursuant to, and subject 448 to the license terms contained in, the Simplified BSD 449 License set forth in Section 4.c of the IETF Trust's 450 Legal Provisions Relating to IETF Documents 451 (http://trustee.ietf.org/license-info). 453 This version of this YANG module is part of RFC XXXX; see 454 the RFC itself for full legal notices."; 456 revision "2018-09-20" { 457 description 458 "Initial version"; 459 reference 460 "RFC XXXX: RESTCONF Client and Server Models"; 461 } 463 // Features 465 feature initiate { 466 description 467 "The 'initiate' feature indicates that the RESTCONF client 468 supports initiating RESTCONF connections to RESTCONF servers 469 using at least one transport (e.g., TLS, etc.)."; 470 } 472 feature tls-initiate { 473 if-feature initiate; 474 description 475 "The 'tls-initiate' feature indicates that the RESTCONF client 476 supports initiating TLS connections to RESTCONF servers. This 477 feature exists as TLS might not be a mandatory to implement 478 transport in the future."; 479 reference 480 "RFC 8040: RESTCONF Protocol"; 481 } 483 feature listen { 484 description 485 "The 'listen' feature indicates that the RESTCONF client 486 supports opening a port to accept RESTCONF server call 487 home connections using at least one transport (e.g., 488 TLS, etc.)."; 489 } 491 feature tls-listen { 492 if-feature listen; 493 description 494 "The 'tls-listen' feature indicates that the RESTCONF client 495 supports opening a port to listen for incoming RESTCONF 496 server call-home TLS connections. This feature exists as 497 TLS might not be a mandatory to implement transport in the 498 future."; 499 reference 500 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 501 } 503 container restconf-client { 504 uses restconf-client-grouping; 505 description 506 "Top-level container for RESTCONF client configuration."; 507 } 509 grouping restconf-client-grouping { 510 description 511 "Top-level grouping for RESTCONF client configuration."; 513 container initiate { 514 if-feature initiate; 515 presence "Enables client to initiate TCP connections"; 516 description 517 "Configures client initiating underlying TCP connections."; 518 list restconf-server { 519 key name; 520 min-elements 1; 521 description 522 "List of RESTCONF servers the RESTCONF client is to 523 initiate connections to in parallel."; 524 leaf name { 525 type string; 526 description 527 "An arbitrary name for the RESTCONF server."; 529 } 530 container endpoints { 531 description 532 "Container for the list of endpoints."; 533 list endpoint { 534 key name; 535 min-elements 1; 536 ordered-by user; 537 description 538 "A non-empty user-ordered list of endpoints for this 539 RESTCONF client to try to connect to in sequence. 540 Defining more than one enables high-availability."; 541 leaf name { 542 type string; 543 description 544 "An arbitrary name for this endpoint."; 545 } 546 choice transport { 547 mandatory true; 548 description 549 "Selects between available transports. This is a 550 'choice' statement so as to support additional 551 transport options to be augmented in."; 552 case tls { 553 if-feature tls-initiate; 554 container tls { 555 description 556 "Specifies TLS-specific transport 557 configuration."; 558 leaf address { 559 type inet:host; 560 mandatory true; 561 description 562 "The IP address or hostname of the endpoint. 563 If a domain name is configured, then the 564 DNS resolution should happen on each usage 565 attempt. If the the DNS resolution results 566 in multiple IP addresses, the IP addresses 567 will be tried according to local preference 568 order until a connection has been established 569 or until all IP addresses have failed."; 570 } 571 leaf port { 572 type inet:port-number; 573 default 443; 574 description 575 "The IP port for this endpoint. The RESTCONF 576 client will use the IANA-assigned well-known 577 port for 'https' (443) if no value is 578 specified."; 579 } 580 uses ts:tls-client-grouping { 581 refine "client-identity/auth-type" { 582 mandatory true; 583 description 584 "RESTCONF clients MUST pass some 585 authentication credentials."; 586 } 587 } 588 } 589 } // end tls 590 } // end transport 591 container connection-type { 592 description 593 "Indicates the kind of connection to use."; 594 choice connection-type { 595 mandatory true; 596 description 597 "Selects between available connection types."; 598 case persistent-connection { 599 container persistent { 600 presence 601 "Indicates that a persistent connection is 602 to be maintained."; 603 description 604 "Maintain a persistent connection to the 605 RESTCONF server. If the connection goes down, 606 immediately start trying to reconnect to it, 607 using the reconnection strategy. This 608 connection type minimizes any RESTCONF server 609 to RESTCONF client data-transfer delay, albeit 610 at the expense of holding resources longer."; 611 container keep-alives { 612 description 613 "Configures the keep-alive policy, to 614 proactively test the aliveness of the TLS 615 server. An unresponsive TLS server will 616 be dropped after approximately max-attempts 617 * max-wait seconds."; 618 leaf max-wait { 619 type uint16 { 620 range "1..max"; 621 } 622 units seconds; 623 default 30; 624 description 625 "Sets the amount of time in seconds after 626 which if no data has been received from 627 the TLS server, a TLS-level message will 628 be sent to test the aliveness of the TLS 629 server."; 630 } 631 leaf max-attempts { 632 type uint8; 633 default 3; 634 description 635 "Sets the maximum number of sequential 636 keep-alive messages that can fail to 637 obtain a response from the TLS server 638 before assuming the TLS server is no 639 longer alive."; 640 } 641 } 642 } 643 } 644 case periodic-connection { 645 container periodic { 646 presence 647 "Indicates that a periodic connection is to be 648 maintained."; 649 description 650 "Periodically connect to the NETCONF server. 651 The RESTCONF server should close the underlying 652 TLS connection upon completing planned 653 activities. 655 This connection type increases resource 656 utilization, albeit with increased delay in 657 RESTCONF server to RESTCONF client 658 interactions."; 659 leaf period { 660 type uint16; 661 units "minutes"; 662 default 60; 663 description 664 "Duration of time between periodic 665 connections."; 666 } 667 leaf anchor-time { 668 type yang:date-and-time { 669 // constrained to minute-level granularity 670 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}' 671 + '(Z|[\+\-]\d{2}:\d{2})'; 672 } 673 description 674 "Designates a timestamp before or after which 675 a series of periodic connections are 676 determined. The periodic connections occur 677 at a whole multiple interval from the anchor 678 time. For example, for an anchor time is 15 679 minutes past midnight and a period interval 680 of 24 hours, then a periodic connection will 681 occur 15 minutes past midnight everyday."; 682 } 683 leaf idle-timeout { 684 type uint16; 685 units "seconds"; 686 default 120; // two minutes 687 description 688 "Specifies the maximum number of seconds 689 that the underlying TLS session may remain 690 idle. A TLS session will be dropped if it 691 is idle for an interval longer than this 692 number of seconds If set to zero, then the 693 RESTCONF client will never drop a session 694 because it is idle."; 695 } 696 } 697 } // end periodic-connection 698 } // end connection-type 699 } // end connection-type 700 container reconnect-strategy { 701 description 702 "The reconnection strategy directs how a RESTCONF 703 client reconnects to a RESTCONF server, after 704 discovering its connection to the server has 705 dropped, even if due to a reboot. The RESTCONF 706 client starts with the specified endpoint and 707 tries to connect to it max-attempts times before 708 trying the next endpoint in the list (round 709 robin)."; 710 leaf start-with { 711 type enumeration { 712 enum first-listed { 713 description 714 "Indicates that reconnections should start 715 with the first endpoint listed."; 716 } 717 enum last-connected { 718 description 719 "Indicates that reconnections should start 720 with the endpoint last connected to. If 721 no previous connection has ever been 722 established, then the first endpoint 723 configured is used. RESTCONF clients 724 SHOULD be able to remember the last 725 endpoint connected to across reboots."; 726 } 727 enum random-selection { 728 description 729 "Indicates that reconnections should start with 730 a random endpoint."; 731 } 732 } 733 default first-listed; 734 description 735 "Specifies which of the RESTCONF server's 736 endpoints the RESTCONF client should start 737 with when trying to connect to the RESTCONF 738 server."; 739 } 740 leaf max-attempts { 741 type uint8 { 742 range "1..max"; 743 } 744 default 3; 745 description 746 "Specifies the number times the RESTCONF client 747 tries to connect to a specific endpoint before 748 moving on to the next endpoint in the list 749 (round robin)."; 750 } 751 } // end reconnect-strategy 752 } // end endpoint 753 } // end endpoints 754 } // end restconf-server 755 } // end initiate 757 container listen { 758 if-feature listen; 759 presence "Enables client to accept call-home connections"; 760 description 761 "Configures client accepting call-home TCP connections."; 763 leaf idle-timeout { 764 type uint16; 765 units "seconds"; 766 default 3600; // one hour 767 description 768 "Specifies the maximum number of seconds that an 769 underlying TLS session may remain idle. A TLS session 770 will be dropped if it is idle for an interval longer 771 than this number of seconds. If set to zero, then 772 the server will never drop a session because it is 773 idle. Sessions that have a notification subscription 774 active are never dropped."; 775 } 777 list endpoint { 778 key name; 779 min-elements 1; 780 description 781 "List of endpoints to listen for RESTCONF connections."; 782 leaf name { 783 type string; 784 description 785 "An arbitrary name for the RESTCONF listen endpoint."; 786 } 787 choice transport { 788 mandatory true; 789 description 790 "Selects between available transports. This is a 791 'choice' statement so as to support additional 792 transport options to be augmented in."; 793 case tls { 794 if-feature tls-listen; 795 container tls { 796 description 797 "TLS-specific listening configuration for inbound 798 connections."; 799 leaf address { 800 type inet:ip-address; 801 description 802 "The IP address to listen on for incoming call- 803 home connections. The RESTCONF client will 804 listen on all configured interfaces if no 805 value is specified. INADDR_ANY (0.0.0.0) or 806 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST 807 be used when the server is to listen on all 808 IPv4 or IPv6 addresses, respectively."; 809 } 810 leaf port { 811 type inet:port-number; 812 default 4336; 813 description 814 "The port number to listen on for call-home 815 connections. The RESTCONF client will listen 816 on the IANA-assigned well-known port for 817 'restconf-ch-tls' (4336) if no value is 818 specified."; 819 } 820 uses ts:tls-client-grouping { 821 refine "client-identity/auth-type" { 822 mandatory true; 823 description 824 "RESTCONF clients MUST pass some authentication 825 credentials."; 826 } 827 } 828 } 829 } 830 } // end transport 831 } // end endpoint 832 } // end listen 833 } // end restconf-client 834 } 835 837 3. The RESTCONF Server Model 839 The RESTCONF server model presented in this section supports servers 840 both listening for connections as well as initiating call-home 841 connections. 843 All private keys and trusted certificates are held in the keystore 844 model defined in [I-D.ietf-netconf-keystore]. 846 YANG feature statements are used to enable implementations to 847 advertise which parts of the model the RESTCONF server supports. 849 3.1. Tree Diagram 851 The following tree diagram [RFC8340] provides an overview of the data 852 model for the "ietf-restconf-server" module. Just the container is 853 displayed below, but there is also a reusable grouping called 854 "restconf-server-grouping" that the container is using. 856 [Note: '\' line wrapping for formatting only] 858 module: ietf-restconf-server 859 +--rw restconf-server 860 +--rw listen! {listen}? 861 | +--rw endpoint* [name] 862 | +--rw name string 863 | +--rw (transport) 864 | +--:(tls) {tls-listen}? 865 | +--rw tls 866 | +--rw address? inet:ip-address 867 | +--rw port? inet:port-number 868 | +--rw server-identity 869 | | +--rw (local-or-keystore) 870 | | +--:(local) {local-keys-supported}? 871 | | | +--rw algorithm? 872 | | | | ct:key-algorithm-ref 873 | | | +--rw public-key? binary 874 | | | +--rw private-key? union 875 | | | +---x generate-hidden-key 876 | | | | +---w input 877 | | | | +---w algorithm 878 | | | | ct:key-algorithm-ref 879 | | | +---x install-hidden-key 880 | | | | +---w input 881 | | | | +---w algorithm 882 | | | | | ct:key-algorithm-ref 883 | | | | +---w public-key? binary 884 | | | | +---w private-key? binary 885 | | | +--rw cert 886 | | | | ct:end-entity-cert-cms 887 | | | +---n certificate-expiration 888 | | | +-- expiration-date? 889 | | | yang:date-and-time 890 | | +--:(keystore) {keystore-supported}? 891 | | +--rw reference? 892 | | ks:asymmetric-key-certificate-r\ 893 ef 894 | +--rw client-auth 895 | | +--rw pinned-ca-certs? 896 | | | ta:pinned-certificates-ref 897 | | | {ta:x509-certificates}? 898 | | +--rw pinned-client-certs? 899 | | | ta:pinned-certificates-ref 900 | | | {ta:x509-certificates}? 901 | | +--rw cert-maps 902 | | +--rw cert-to-name* [id] 903 | | +--rw id uint32 904 | | +--rw fingerprint 905 | | | x509c2n:tls-fingerprint 906 | | +--rw map-type identityref 907 | | +--rw name string 908 | +--rw hello-params 909 | {tls-server-hello-params-config}? 910 | +--rw tls-versions 911 | | +--rw tls-version* identityref 912 | +--rw cipher-suites 913 | +--rw cipher-suite* identityref 914 +--rw call-home! {call-home}? 915 +--rw restconf-client* [name] 916 +--rw name string 917 +--rw endpoints 918 | +--rw endpoint* [name] 919 | +--rw name string 920 | +--rw (transport) 921 | +--:(tls) {tls-call-home}? 922 | +--rw tls 923 | +--rw address inet:host 924 | +--rw port? inet:port-number 925 | +--rw server-identity 926 | | +--rw (local-or-keystore) 927 | | +--:(local) {local-keys-supported}? 928 | | | +--rw algorithm? 929 | | | | ct:key-algorithm-ref 930 | | | +--rw public-key? 931 | | | | binary 932 | | | +--rw private-key? 933 | | | | union 934 | | | +---x generate-hidden-key 935 | | | | +---w input 936 | | | | +---w algorithm 937 | | | | ct:key-algorithm-ref 938 | | | +---x install-hidden-key 939 | | | | +---w input 940 | | | | +---w algorithm 941 | | | | | ct:key-algorithm-ref 942 | | | | +---w public-key? binary 943 | | | | +---w private-key? binary 944 | | | +--rw cert 945 | | | | ct:end-entity-cert-cms 946 | | | +---n certificate-expiration 947 | | | +-- expiration-date? 948 | | | yang:date-and-time 949 | | +--:(keystore) {keystore-supported}? 950 | | +--rw reference? 951 | | ks:asymmetric-key-certifi\ 952 cate-ref 953 | +--rw client-auth 954 | | +--rw pinned-ca-certs? 955 | | | ta:pinned-certificates-ref 956 | | | {ta:x509-certificates}? 957 | | +--rw pinned-client-certs? 958 | | | ta:pinned-certificates-ref 959 | | | {ta:x509-certificates}? 960 | | +--rw cert-maps 961 | | +--rw cert-to-name* [id] 962 | | +--rw id uint32 963 | | +--rw fingerprint 964 | | | x509c2n:tls-fingerprint 965 | | +--rw map-type identityref 966 | | +--rw name string 967 | +--rw hello-params 968 | {tls-server-hello-params-config}? 969 | +--rw tls-versions 970 | | +--rw tls-version* identityref 971 | +--rw cipher-suites 972 | +--rw cipher-suite* identityref 973 +--rw connection-type 974 | +--rw (connection-type) 975 | +--:(persistent-connection) 976 | | +--rw persistent! 977 | | +--rw keep-alives 978 | | +--rw max-wait? uint16 979 | | +--rw max-attempts? uint8 980 | +--:(periodic-connection) 981 | +--rw periodic! 982 | +--rw period? uint16 983 | +--rw anchor-time? yang:date-and-time 984 | +--rw idle-timeout? uint16 985 +--rw reconnect-strategy 986 +--rw start-with? enumeration 987 +--rw max-attempts? uint8 989 3.2. Example Usage 991 The following example illustrates configuring a RESTCONF server to 992 listen for RESTCONF client connections, as well as configuring call- 993 home to one RESTCONF client. 995 This example is consistent with the examples presented in Section 3.2 996 of [I-D.ietf-netconf-keystore]. 998 [Note: '\' line wrapping for formatting only] 1000 1004 1005 1006 1007 netconf/tls 1008 1009
11.22.33.44
1010 1011 ct:secp521r1 1013 base64encodedvalue== 1014 base64encodedvalue== 1015 base64encodedvalue== 1016 1017 1018 explicitly-trusted-client-ca-certs 1020 explicitly-trusted-client-certs 1022 1023 1024 1 1025 11:0A:05:11:00 1026 x509c2n:san-any 1027 1028 1029 2 1030 B3:4F:A1:8C:54 1031 x509c2n:specified 1032 scooby-doo 1033 1034 1035 1036 1037 1038 1040 1041 1042 1043 config-manager 1044 1045 1046 east-data-center 1047 1048
22.33.44.55
1049 1050 ct:secp521r1 1052 base64encodedvalue== 1053 base64encodedvalue== 1054 base64encodedvalue== 1056 1057 1058 explicitly-trusted-client-ca-certs 1060 explicitly-trusted-client-certs 1062 1063 1064 1 1065 11:0A:05:11:00 1066 x509c2n:san-any 1067 1068 1069 2 1070 B3:4F:A1:8C:54 1071 x509c2n:specified 1072 scooby-doo 1073 1074 1075 1076 1077 1078 1079 west-data-center 1080 1081
33.44.55.66
1082 1083 ct:secp521r1 1085 base64encodedvalue== 1086 base64encodedvalue== 1087 base64encodedvalue== 1088 1089 1090 explicitly-trusted-client-ca-certs 1092 explicitly-trusted-client-certs 1094 1095 1096 1 1097 11:0A:05:11:00 1098 x509c2n:san-any 1099 1100 1101 2 1102 B3:4F:A1:8C:54 1103 x509c2n:specified 1104 scooby-doo 1105 1106 1107 1108 1109 1110 1111 1112 1113 300 1114 60 1115 1116 1117 1118 last-connected 1119 3 1120 1121 1122 1123 1125 3.3. YANG Module 1127 This YANG module has normative references to [RFC6991], [RFC7407], 1128 [RFC8040], [RFC8071], and [I-D.ietf-netconf-tls-client-server]. 1130 file "ietf-restconf-server@2018-09-20.yang" 1131 module ietf-restconf-server { 1132 yang-version 1.1; 1134 namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server"; 1135 prefix "rcs"; 1137 import ietf-yang-types { 1138 prefix yang; 1139 reference 1140 "RFC 6991: Common YANG Data Types"; 1141 } 1143 import ietf-inet-types { 1144 prefix inet; 1145 reference 1146 "RFC 6991: Common YANG Data Types"; 1147 } 1149 import ietf-x509-cert-to-name { 1150 prefix x509c2n; 1151 reference 1152 "RFC 7407: A YANG Data Model for SNMP Configuration"; 1153 } 1155 import ietf-tls-server { 1156 prefix ts; 1157 revision-date 2018-09-20; // stable grouping definitions 1158 reference 1159 "RFC ZZZZ: YANG Groupings for TLS Clients and TLS Servers"; 1160 } 1162 organization 1163 "IETF NETCONF (Network Configuration) Working Group"; 1165 contact 1166 "WG Web: 1167 WG List: 1169 Author: Kent Watsen 1170 1172 Author: Gary Wu 1173 1175 Author: Juergen Schoenwaelder 1176 "; 1178 description 1179 "This module contains a collection of YANG definitions for 1180 configuring RESTCONF servers. 1182 Copyright (c) 2017 IETF Trust and the persons identified as 1183 authors of the code. All rights reserved. 1185 Redistribution and use in source and binary forms, with or 1186 without modification, is permitted pursuant to, and subject 1187 to the license terms contained in, the Simplified BSD 1188 License set forth in Section 4.c of the IETF Trust's 1189 Legal Provisions Relating to IETF Documents 1190 (http://trustee.ietf.org/license-info). 1192 This version of this YANG module is part of RFC XXXX; see 1193 the RFC itself for full legal notices."; 1195 revision "2018-09-20" { 1196 description 1197 "Initial version"; 1199 reference 1200 "RFC XXXX: RESTCONF Client and Server Models"; 1201 } 1203 // Features 1205 feature listen { 1206 description 1207 "The 'listen' feature indicates that the RESTCONF server 1208 supports opening a port to accept RESTCONF client connections 1209 using at least one transport (e.g., TLS, etc.)."; 1210 } 1212 feature tls-listen { 1213 if-feature listen; 1214 description 1215 "The 'tls-listen' feature indicates that the RESTCONF server 1216 supports opening a port to listen for incoming RESTCONF 1217 client connections. This feature exists as TLS might not 1218 be a mandatory to implement transport in the future."; 1219 reference 1220 "RFC 8040: RESTCONF Protocol"; 1221 } 1223 feature call-home { 1224 description 1225 "The 'call-home' feature indicates that the RESTCONF 1226 server supports initiating RESTCONF call home connections 1227 to RESTCONF clients using at least one transport (e.g., 1228 TLS, etc.)."; 1229 reference 1230 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 1231 } 1233 feature tls-call-home { 1234 if-feature call-home; 1235 description 1236 "The 'tls-call-home' feature indicates that the RESTCONF 1237 server supports initiating connections to RESTCONF clients. 1238 This feature exists as TLS might not be a mandatory to 1239 implement transport in the future."; 1240 reference 1241 "RFC 8071: NETCONF Call Home and RESTCONF Call Home"; 1242 } 1244 container restconf-server { 1245 uses restconf-server-grouping; 1246 description 1247 "Top-level container for RESTCONF server configuration."; 1248 } 1250 grouping restconf-server-grouping { 1251 description 1252 "Top-level grouping for RESTCONF server configuration."; 1254 container listen { 1255 if-feature listen; 1256 presence "Enables server to listen for TCP connections"; 1257 description "Configures listen behavior"; 1258 list endpoint { 1259 key name; 1260 min-elements 1; 1261 description 1262 "List of endpoints to listen for RESTCONF connections."; 1263 leaf name { 1264 type string; 1265 description 1266 "An arbitrary name for the RESTCONF listen endpoint."; 1267 } 1268 choice transport { 1269 mandatory true; 1270 description 1271 "Selects between available transports. This is a 1272 'choice' statement so as to support additional 1273 transport options to be augmented in."; 1274 case tls { 1275 if-feature tls-listen; 1276 container tls { 1277 description 1278 "TLS-specific listening configuration for inbound 1279 connections."; 1280 leaf address { 1281 type inet:ip-address; 1282 description 1283 "The IP address to listen on for incoming 1284 connections. The RESTCONF server will listen 1285 on all configured interfaces if no value is 1286 specified. INADDR_ANY (0.0.0.0) or INADDR6_ANY 1287 (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be used when 1288 the server is to listen on all IPv4 or IPv6 1289 addresses, respectively."; 1290 } 1291 leaf port { 1292 type inet:port-number; 1293 default 443; 1294 description 1295 "The local port number to listen on. If no value 1296 is specified, the IANA-assigned port value for 1297 'https' (443) is used."; 1298 } 1299 uses ts:tls-server-grouping { 1300 refine "client-auth" { 1301 must 'pinned-ca-certs or pinned-client-certs'; 1302 description 1303 "RESTCONF servers MUST be able to validate 1304 clients."; 1305 } 1306 augment "client-auth" { 1307 description 1308 "Augments in the cert-to-name structure, 1309 so the RESTCONF server can map TLS-layer 1310 client certificates to RESTCONF usernames."; 1311 container cert-maps { 1312 uses x509c2n:cert-to-name; 1313 description 1314 "The cert-maps container is used by a TLS- 1315 based RESTCONF server to map the RESTCONF 1316 client's presented X.509 certificate to 1317 a RESTCONF username. If no matching and 1318 valid cert-to-name list entry can be found, 1319 then the RESTCONF server MUST close the 1320 connection, and MUST NOT accept RESTCONF 1321 messages over it."; 1322 reference 1323 "RFC 7407: A YANG Data Model for SNMP 1324 Configuration."; 1325 } 1326 } 1327 } 1328 } // end tls container 1329 } // end tls case 1330 } // end transport 1331 } // end endpoint 1332 } // end listen 1334 container call-home { 1335 if-feature call-home; 1336 presence "Enables server to initiate TCP connections"; 1337 description "Configures call-home behavior"; 1338 list restconf-client { 1339 key name; 1340 min-elements 1; 1341 description 1342 "List of RESTCONF clients the RESTCONF server is to 1343 initiate call-home connections to in parallel."; 1344 leaf name { 1345 type string; 1346 description 1347 "An arbitrary name for the remote RESTCONF client."; 1348 } 1349 container endpoints { 1350 description 1351 "Container for the list of endpoints."; 1352 list endpoint { 1353 key name; 1354 min-elements 1; 1355 ordered-by user; 1356 description 1357 "User-ordered list of endpoints for this RESTCONF 1358 client. Defining more than one enables high- 1359 availability."; 1360 leaf name { 1361 type string; 1362 description 1363 "An arbitrary name for this endpoint."; 1364 } 1365 choice transport { 1366 mandatory true; 1367 description 1368 "Selects between available transports. This is a 1369 'choice' statement so as to support additional 1370 transport options to be augmented in."; 1371 case tls { 1372 if-feature tls-call-home; 1373 container tls { 1374 description 1375 "Specifies TLS-specific call-home transport 1376 configuration."; 1377 leaf address { 1378 type inet:host; 1379 mandatory true; 1380 description 1381 "The IP address or hostname of the endpoint. 1382 If a domain name is configured, then the 1383 DNS resolution should happen on each usage 1384 attempt. If the DNS resolution results in 1385 multiple IP addresses, the IP addresses will 1386 be tried according to local preference order 1387 until a connection has been established or 1388 until all IP addresses have failed."; 1389 } 1390 leaf port { 1391 type inet:port-number; 1392 default 4336; 1393 description 1394 "The IP port for this endpoint. The RESTCONF 1395 server will use the IANA-assigned well-known 1396 port for 'restconf-ch-tls' (4336) if no value 1397 is specified."; 1398 } 1399 uses ts:tls-server-grouping { 1400 refine "client-auth" { 1401 must 'pinned-ca-certs or pinned-client-certs'; 1402 description 1403 "RESTCONF servers MUST be able to validate 1404 clients."; 1405 } 1406 augment "client-auth" { 1407 description 1408 "Augments in the cert-to-name structure, 1409 so the RESTCONF server can map TLS-layer 1410 client certificates to RESTCONF usernames."; 1411 container cert-maps { 1412 uses x509c2n:cert-to-name; 1413 description 1414 "The cert-maps container is used by a 1415 TLS-based RESTCONF server to map the 1416 RESTCONF client's presented X.509 1417 certificate to a RESTCONF username. If 1418 no matching and valid cert-to-name list 1419 entry can be found, then the RESTCONF 1420 server MUST close the connection, and 1421 MUST NOT accept RESTCONF messages over 1422 it."; 1423 reference 1424 "RFC 7407: A YANG Data Model for SNMP 1425 Configuration."; 1426 } 1427 } 1428 } 1429 } 1430 } 1431 } // end transport 1432 } // end endpoint 1433 } // end endpoints 1434 container connection-type { 1435 description 1436 "Indicates the RESTCONF client's preference for how the 1437 RESTCONF server's connection is maintained."; 1439 choice connection-type { 1440 mandatory true; 1441 description 1442 "Selects between available connection types."; 1443 case persistent-connection { 1444 container persistent { 1445 presence 1446 "Indicates that a persistent connection is to be 1447 maintained."; 1448 description 1449 "Maintain a persistent connection to the RESTCONF 1450 client. If the connection goes down, immediately 1451 start trying to reconnect to it, using the 1452 reconnection strategy. 1454 This connection type minimizes any RESTCONF 1455 client to RESTCONF server data-transfer delay, 1456 albeit at the expense of holding resources 1457 longer."; 1458 container keep-alives { 1459 description 1460 "Configures the keep-alive policy, to 1461 proactively test the aliveness of the TLS 1462 client. An unresponsive TLS client will 1463 be dropped after approximately (max-attempts 1464 * max-wait) seconds."; 1465 reference 1466 "RFC 8071: NETCONF Call Home and RESTCONF 1467 Call Home, Section 4.1, item S7"; 1468 leaf max-wait { 1469 type uint16 { 1470 range "1..max"; 1471 } 1472 units seconds; 1473 default 30; 1474 description 1475 "Sets the amount of time in seconds after 1476 which if no data has been received from 1477 the TLS client, a TLS-level message will 1478 be sent to test the aliveness of the TLS 1479 client."; 1480 } 1481 leaf max-attempts { 1482 type uint8; 1483 default 3; 1484 description 1485 "Sets the maximum number of sequential keep- 1486 alive messages that can fail to obtain a 1487 response from the TLS client before assuming 1488 the TLS client is no longer alive."; 1489 } 1490 } 1491 } 1492 } 1493 case periodic-connection { 1494 container periodic { 1495 presence 1496 "Indicates that a periodic connection is to be 1497 maintained."; 1498 description 1499 "Periodically connect to the RESTCONF client. The 1500 RESTCONF client should close the underlying TLS 1501 connection upon completing planned activities. 1503 This connection type increases resource 1504 utilization, albeit with increased delay in 1505 RESTCONF client to RESTCONF client interactions."; 1506 leaf period { 1507 type uint16; 1508 units "minutes"; 1509 default 60; 1510 description 1511 "Duration of time between periodic connections."; 1512 } 1513 leaf anchor-time { 1514 type yang:date-and-time { 1515 // constrained to minute-level granularity 1516 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}' 1517 + '(Z|[\+\-]\d{2}:\d{2})'; 1518 } 1519 description 1520 "Designates a timestamp before or after which a 1521 series of periodic connections are determined. 1522 The periodic connections occur at a whole 1523 multiple interval from the anchor time. For 1524 example, for an anchor time is 15 minutes past 1525 midnight and a period interval of 24 hours, then 1526 a periodic connection will occur 15 minutes past 1527 midnight everyday."; 1528 } 1529 leaf idle-timeout { 1530 type uint16; 1531 units "seconds"; 1532 default 120; // two minutes 1533 description 1534 "Specifies the maximum number of seconds that 1535 the underlying TLS session may remain idle. 1536 A TLS session will be dropped if it is idle 1537 for an interval longer than this number of 1538 seconds. If set to zero, then the server 1539 will never drop a session because it is idle."; 1540 } 1541 } 1542 } 1543 } 1544 } 1545 container reconnect-strategy { 1546 description 1547 "The reconnection strategy directs how a RESTCONF server 1548 reconnects to a RESTCONF client after discovering its 1549 connection to the client has dropped, even if due to a 1550 reboot. The RESTCONF server starts with the specified 1551 endpoint and tries to connect to it max-attempts times 1552 before trying the next endpoint in the list (round 1553 robin)."; 1554 leaf start-with { 1555 type enumeration { 1556 enum first-listed { 1557 description 1558 "Indicates that reconnections should start with 1559 the first endpoint listed."; 1560 } 1561 enum last-connected { 1562 description 1563 "Indicates that reconnections should start with 1564 the endpoint last connected to. If no previous 1565 connection has ever been established, then the 1566 first endpoint configured is used. RESTCONF 1567 servers SHOULD be able to remember the last 1568 endpoint connected to across reboots."; 1569 } 1570 enum random-selection { 1571 description 1572 "Indicates that reconnections should start with 1573 a random endpoint."; 1574 } 1575 } 1576 default first-listed; 1577 description 1578 "Specifies which of the RESTCONF client's endpoints 1579 the RESTCONF server should start with when trying 1580 to connect to the RESTCONF client."; 1581 } 1582 leaf max-attempts { 1583 type uint8 { 1584 range "1..max"; 1585 } 1586 default 3; 1587 description 1588 "Specifies the number times the RESTCONF server tries 1589 to connect to a specific endpoint before moving on to 1590 the next endpoint in the list (round robin)."; 1591 } 1592 } 1593 } 1594 } 1595 } 1596 } 1597 1599 4. Security Considerations 1601 The YANG module defined in this document uses a grouping defined in 1602 [I-D.ietf-netconf-tls-client-server]. Please see the Security 1603 Considerations section in that document for concerns related that 1604 grouping. 1606 The YANG module defined in this document is designed to be accessed 1607 via YANG based management protocols, such as NETCONF [RFC6241] and 1608 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1609 implement secure transport layers (e.g., SSH, TLS) with mutual 1610 authentication. 1612 The NETCONF access control model (NACM) [RFC8341] provides the means 1613 to restrict access for particular users to a pre-configured subset of 1614 all available protocol operations and content. 1616 There are a number of data nodes defined in this YANG module that are 1617 writable/creatable/deletable (i.e., config true, which is the 1618 default). These data nodes may be considered sensitive or vulnerable 1619 in some network environments. Write operations (e.g., edit-config) 1620 to these data nodes without proper protection can have a negative 1621 effect on network operations. These are the subtrees and data nodes 1622 and their sensitivity/vulnerability: 1624 /: The entire data trees defined by the modules defined in this 1625 draft are sensitive to write operations. For instance, the 1626 addition or removal of references to keys, certificates, 1627 trusted anchors, etc., can dramatically alter the implemented 1628 security policy. However, no NACM annotations are applied as 1629 the data SHOULD be editable by users other than a designated 1630 'recovery session'. 1632 Some of the readable data nodes in this YANG module may be considered 1633 sensitive or vulnerable in some network environments. It is thus 1634 important to control read access (e.g., via get, get-config, or 1635 notification) to these data nodes. These are the subtrees and data 1636 nodes and their sensitivity/vulnerability: 1638 NONE 1640 Some of the RPC operations in this YANG module may be considered 1641 sensitive or vulnerable in some network environments. It is thus 1642 important to control access to these operations. These are the 1643 operations and their sensitivity/vulnerability: 1645 NONE 1647 5. IANA Considerations 1649 5.1. The IETF XML Registry 1651 This document registers two URIs in the "ns" subregistry of the IETF 1652 XML Registry [RFC3688]. Following the format in [RFC3688], the 1653 following registrations are requested: 1655 URI: urn:ietf:params:xml:ns:yang:ietf-restconf-client 1656 Registrant Contact: The NETCONF WG of the IETF. 1657 XML: N/A, the requested URI is an XML namespace. 1659 URI: urn:ietf:params:xml:ns:yang:ietf-restconf-server 1660 Registrant Contact: The NETCONF WG of the IETF. 1661 XML: N/A, the requested URI is an XML namespace. 1663 5.2. The YANG Module Names Registry 1665 This document registers two YANG modules in the YANG Module Names 1666 registry [RFC6020]. Following the format in [RFC6020], the the 1667 following registrations are requested: 1669 name: ietf-restconf-client 1670 namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-client 1671 prefix: ncc 1672 reference: RFC XXXX 1674 name: ietf-restconf-server 1675 namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server 1676 prefix: ncs 1677 reference: RFC XXXX 1679 6. References 1681 6.1. Normative References 1683 [I-D.ietf-netconf-keystore] 1684 Watsen, K., "YANG Data Model for a Centralized Keystore 1685 Mechanism", draft-ietf-netconf-keystore-06 (work in 1686 progress), September 2018. 1688 [I-D.ietf-netconf-tls-client-server] 1689 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and 1690 TLS Servers", draft-ietf-netconf-tls-client-server-06 1691 (work in progress), June 2018. 1693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1694 Requirement Levels", BCP 14, RFC 2119, 1695 DOI 10.17487/RFC2119, March 1997, 1696 . 1698 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1699 the Network Configuration Protocol (NETCONF)", RFC 6020, 1700 DOI 10.17487/RFC6020, October 2010, 1701 . 1703 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1704 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1705 . 1707 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 1708 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 1709 December 2014, . 1711 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1712 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1713 . 1715 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1716 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1717 . 1719 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1720 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1721 . 1723 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1724 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1725 May 2017, . 1727 6.2. Informative References 1729 [I-D.ietf-netconf-netconf-client-server] 1730 Watsen, K. and G. Wu, "NETCONF Client and Server Models", 1731 draft-ietf-netconf-netconf-client-server-06 (work in 1732 progress), June 2018. 1734 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1735 DOI 10.17487/RFC3688, January 2004, 1736 . 1738 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1739 and A. Bierman, Ed., "Network Configuration Protocol 1740 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1741 . 1743 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1744 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1745 . 1747 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1748 Access Control Model", STD 91, RFC 8341, 1749 DOI 10.17487/RFC8341, March 2018, 1750 . 1752 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1753 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1754 . 1756 Appendix A. Change Log 1758 A.1. 00 to 01 1760 o Renamed "keychain" to "keystore". 1762 A.2. 01 to 02 1764 o Filled in previously missing 'ietf-restconf-client' module. 1766 o Updated the ietf-restconf-server module to accomodate new grouping 1767 'ietf-tls-server-grouping'. 1769 A.3. 02 to 03 1771 o Refined use of tls-client-grouping to add a must statement 1772 indicating that the TLS client must specify a client-certificate. 1774 o Changed restconf-client??? to be a grouping (not a container). 1776 A.4. 03 to 04 1778 o Added RFC 8174 to Requirements Language Section. 1780 o Replaced refine statement in ietf-restconf-client to add a 1781 mandatory true. 1783 o Added refine statement in ietf-restconf-server to add a must 1784 statement. 1786 o Now there are containers and groupings, for both the client and 1787 server models. 1789 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 1791 o Updated examples to inline key and certificates (no longer a 1792 leafref to keystore) 1794 A.5. 04 to 05 1796 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 1798 o Updated examples to inline key and certificates (no longer a 1799 leafref to keystore) 1801 A.6. 05 to 06 1803 o Fixed change log missing section issue. 1805 o Updated examples to match latest updates to the crypto-types, 1806 trust-anchors, and keystore drafts. 1808 o Reduced line length of the YANG modules to fit within 69 columns. 1810 A.7. 06 to 07 1812 o removed "idle-timeout" from "persistent" connection config. 1814 o Added "random-selection" for reconnection-strategy's "starts-with" 1815 enum. 1817 o Replaced "connection-type" choice default (persistent) with 1818 "mandatory true". 1820 o Reduced the periodic-connection's "idle-timeout" from 5 to 2 1821 minutes. 1823 o Replaced reconnect-timeout with period/anchor-time combo. 1825 Acknowledgements 1827 The authors would like to thank for following for lively discussions 1828 on list and in the halls (ordered by last name): Andy Bierman, Martin 1829 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David 1830 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, 1831 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. 1833 Author's Address 1835 Kent Watsen 1836 Juniper Networks 1838 EMail: kwatsen@juniper.net