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