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