idnits 2.17.1 draft-ietf-netconf-restconf-client-server-01.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 333 has weird spacing: '...rw name str...' == Line 351 has weird spacing: '...erprint x50...' == Line 364 has weird spacing: '...address ine...' == Line 378 has weird spacing: '...erprint x50...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 3, 2016) is 2730 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 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 J. Schoenwaelder 5 Expires: May 7, 2017 Jacobs University Bremen 6 November 3, 2016 8 RESTCONF Client and Server Models 9 draft-ietf-netconf-restconf-client-server-01 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 draft-ietf-netconf-keystore 32 o draft-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 "YYYY" --> the assigned RFC value for draft-ietf-netconf-restconf 41 o "ZZZZ" --> the assigned RFC value for draft-ietf-netconf-tls- 42 client-server 44 Artwork in this document contains placeholder values for the date of 45 publication of this draft. Please apply the following replacement: 47 o "2016-11-02" --> the publication date of this draft 48 The following two Appendix sections are to be removed prior to 49 publication: 51 o Appendix A. Change Log 53 o Appendix B. Open Issues 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at http://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on May 7, 2017. 72 Copyright Notice 74 Copyright (c) 2016 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (http://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 91 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 92 2. The RESTCONF Client Model . . . . . . . . . . . . . . . . . . 4 93 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 94 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4 95 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 4 97 3. The RESTCONF Server Model . . . . . . . . . . . . . . . . . . 7 98 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 99 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 9 100 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 11 101 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 20 104 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 20 105 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 106 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 108 7.2. Informative References . . . . . . . . . . . . . . . . . 21 109 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 110 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 23 111 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 23 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 114 1. Introduction 116 This document defines two YANG [RFC6020] modules, one module to 117 configure a RESTCONF client and the other module to configure a 118 RESTCONF server [draft-ietf-netconf-restconf]. Both modules support 119 the TLS [RFC5246] transport protocol with both standard RESTCONF and 120 RESTCONF Call Home connections [draft-ietf-netconf-call-home]. 122 1.1. Terminology 124 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 1.2. Tree Diagrams 130 A simplified graphical representation of the data models is used in 131 this document. The meaning of the symbols in these diagrams is as 132 follows: 134 o Brackets "[" and "]" enclose list keys. 136 o Braces "{" and "}" enclose feature names, and indicate that the 137 named feature must be present for the subtree to be present. 139 o Abbreviations before data node names: "rw" means configuration 140 (read-write) and "ro" state data (read-only). 142 o Symbols after data node names: "?" means an optional node, "!" 143 means a presence container, and "*" denotes a list and leaf-list. 145 o Parentheses enclose choice and case nodes, and case nodes are also 146 marked with a colon (":"). 148 o Ellipsis ("...") stands for contents of subtrees that are not 149 shown. 151 2. The RESTCONF Client Model 153 EDITOR NOTE: Please ignore this section, it is incomplete. 155 The RESTCONF client model presented in this section supports both 156 clients initiating connections to servers, as well as clients 157 listening for connections from servers calling home. 159 This model supports both TLS transport protocols using the TLS client 160 groupings defined in [draft-ietf-netconf-tls-client-server]. 162 All private keys and trusted certificates are held in the keystore 163 model defined in [draft-ietf-netconf-keystore]. 165 YANG feature statements are used to enable implementations to 166 advertise which parts of the model the RESTCONF client supports. 168 2.1. Tree Diagram 170 Note: all lines are folded at column 71 with no '\' character. 172 module: ietf-restconf-client 173 +--rw restconf-client 174 +--rw initiate {tls-initiate}? 175 +--rw listen {tls-listen}? 177 2.2. Example Usage 179 The following example illustrates configuring a RESTCONF client to 180 initiate connections, as well as listening for call-home connections. 182 This example is consistent with the examples presented in Section 2.2 183 of [draft-ietf-netconf-keystore]. 185 FIXME 187 2.3. YANG Model 189 This YANG module imports YANG types from [RFC6991] and [RFC7407]. 191 file "ietf-restconf-client@2016-11-02.yang" 192 // Editor's Note: 193 // This module is incomplete at this time. Below is 194 // just a skeleton so there's something in the draft. 195 // Please ignore this module for now! 197 module ietf-restconf-client { 198 yang-version 1.1; 200 namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-client"; 201 prefix "rcc"; 203 /* 204 import ietf-inet-types { 205 prefix inet; 206 reference 207 "RFC 6991: Common YANG Data Types"; 208 } 210 //import ietf-netconf-acm { 211 // prefix nacm; 212 // reference 213 // "RFC 6536: Network Configuration Protocol (NETCONF) 214 // Access Control Model"; 215 //} 217 import ietf-x509-cert-to-name { 218 prefix x509c2n; 219 reference 220 "RFC 7407: A YANG Data Model for SNMP Configuration"; 221 } 223 import ietf-tls-client { 224 prefix ts; 225 revision-date 2016-11-02; // stable grouping definitions 226 reference 227 "RFC ZZZZ: TLS Client and Server Models"; 228 } 229 */ 230 organization 231 "IETF NETCONF (Network Configuration) Working Group"; 233 contact 234 "WG Web: 235 WG List: 237 WG Chair: Mehmet Ersue 238 240 WG Chair: Mahesh Jethanandani 241 243 Editor: Kent Watsen 244 "; 246 description 247 "This module contains a collection of YANG definitions for 248 configuring RESTCONF servers. 250 Copyright (c) 2014 IETF Trust and the persons identified as 251 authors of the code. All rights reserved. 253 Redistribution and use in source and binary forms, with or 254 without modification, is permitted pursuant to, and subject 255 to the license terms contained in, the Simplified BSD 256 License set forth in Section 4.c of the IETF Trust's 257 Legal Provisions Relating to IETF Documents 258 (http://trustee.ietf.org/license-info). 260 This version of this YANG module is part of RFC XXXX; see 261 the RFC itself for full legal notices."; 263 revision "2016-11-02" { 264 description 265 "Initial version"; 266 reference 267 "RFC XXXX: RESTCONF Client and Server Models"; 268 } 270 // Features 272 feature tls-initiate { 273 description 274 "The tls-initiate feature indicates that the RESTCONF client 275 supports initiating TLS connections to RESTCONF servers."; 276 reference 277 "RFC YYYY: RESTCONF Protocol"; 278 } 280 feature tls-listen { 281 description 282 "The tls-listen feature indicates that the RESTCONF client 283 supports opening a port to listen for incoming RESTCONF 284 server call-home TLS connections."; 285 reference 286 "RFC AAAA: NETCONF Call Home and RESTCONF Call Home"; 288 } 290 container restconf-client { 291 description 292 "Top-level container for RESTCONF client configuration."; 293 container initiate { 294 if-feature tls-initiate; 295 description 296 "Configures client intiating underlying TCP connections."; 297 } 298 container listen { 299 if-feature tls-listen; 300 description 301 "Configures client accepting call-home TCP connections."; 302 } 303 } 305 } 307 309 3. The RESTCONF Server Model 311 The RESTCONF Server model presented in this section supports servers 312 both listening for connections as well as initiating call-home 313 connections. 315 This model supports the TLS using the TLS server groupings defined in 316 [draft-ietf-netconf-tls-client-server]. 318 All private keys and trusted certificates are held in the keystore 319 model defined in [draft-ietf-netconf-keystore]. 321 YANG feature statements are used to enable implementations to 322 advertise which parts of the model the RESTCONF server supports. 324 3.1. Tree Diagram 326 Note: all lines are folded at column 71 with no '\' character. 328 module: ietf-restconf-server 329 +--rw restconf-server 330 +--rw listen {listen}? 331 | +--rw max-sessions? uint16 332 | +--rw endpoint* [name] 333 | +--rw name string 334 | +--rw (transport) 335 | +--:(tls) {tls-listen}? 336 | +--rw tls 337 | +--rw address? inet:ip-address 338 | +--rw port? inet:port-number 339 | +--rw certificates 340 | | +--rw certificate* [name] 341 | | +--rw name -> /ks:keystore/private-keys/ 342 private-key/certificate-chains/certificate-chain/name 343 | +--rw client-auth 344 | +--rw trusted-ca-certs? -> /ks:keystore/ 345 trusted-certificates/name 346 | +--rw trusted-client-certs? -> /ks:keystore/ 347 trusted-certificates/name 348 | +--rw cert-maps 349 | +--rw cert-to-name* [id] 350 | +--rw id uint32 351 | +--rw fingerprint x509c2n:tls-fingerp 352 rint 353 | +--rw map-type identityref 354 | +--rw name string 355 +--rw call-home {call-home}? 356 +--rw restconf-client* [name] 357 +--rw name string 358 +--rw (transport) 359 | +--:(tls) {tls-call-home}? 360 | +--rw tls 361 | +--rw endpoints 362 | | +--rw endpoint* [name] 363 | | +--rw name string 364 | | +--rw address inet:host 365 | | +--rw port? inet:port-number 366 | +--rw certificates 367 | | +--rw certificate* [name] 368 | | +--rw name -> /ks:keystore/private-keys/ 369 private-key/certificate-chains/certificate-chain/name 370 | +--rw client-auth 371 | +--rw trusted-ca-certs? -> /ks:keystore/ 372 trusted-certificates/name 373 | +--rw trusted-client-certs? -> /ks:keystore/ 374 trusted-certificates/name 375 | +--rw cert-maps 376 | +--rw cert-to-name* [id] 377 | +--rw id uint32 378 | +--rw fingerprint x509c2n:tls-fingerp 379 rint 380 | +--rw map-type identityref 381 | +--rw name string 382 +--rw connection-type 383 | +--rw (connection-type)? 384 | +--:(persistent-connection) 385 | | +--rw persistent! 386 | | +--rw keep-alives 387 | | +--rw max-wait? uint16 388 | | +--rw max-attempts? uint8 389 | +--:(periodic-connection) 390 | +--rw periodic! 391 | +--rw reconnect-timeout? uint16 392 +--rw reconnect-strategy 393 +--rw start-with? enumeration 394 +--rw max-attempts? uint8 396 3.2. Example Usage 398 The following example illustrates configuring a RESTCONF server to 399 listen for RESTCONF client connections, as well as configuring call- 400 home to one RESTCONF client. 402 This example is consistent with the examples presented in Section 2.2 403 of [draft-ietf-netconf-keystore]. 405 408 409 410 411 netconf/tls 412 413
11.22.33.44
414 415 ex-key-sect571r1-cert 416 417 418 419 deployment-specific-ca-certs 420 421 422 explicitly-trusted-client-certs 423 424 425 426 1 427 11:0A:05:11:00 428 x509c2n:san-any 429 430 431 2 432 B3:4F:A1:8C:54 433 x509c2n:specified 434 scooby-doo 435 436 437 438 440 441 443 444 445 446 config-manager 447 448 449 450 east-data-center 451
22.33.44.55
452 453 454 west-data-center 455
33.44.55.66
456 457 458 459 ex-key-sect571r1-cert 460 461 462 463 deployment-specific-ca-certs 464 465 466 explicitly-trusted-client-certs 467 468 469 470 1 471 11:0A:05:11:00 472 x509c2n:san-any 473 474 475 2 476 B3:4F:A1:8C:54 477 x509c2n:specified 478 scooby-doo 480 481 482 483 484 485 486 300 487 60 488 489 490 491 last-connected 492 3 493 494 495 497 499 3.3. YANG Model 501 This YANG module imports YANG types from [RFC6991] and [RFC7407]. 503 file "ietf-restconf-server@2016-11-02.yang" 505 module ietf-restconf-server { 506 yang-version 1.1; 508 namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server"; 509 prefix "rcs"; 511 //import ietf-netconf-acm { 512 // prefix nacm; 513 // reference 514 // "RFC 6536: Network Configuration Protocol (NETCONF) 515 // Access Control Model"; 516 //} 518 import ietf-inet-types { 519 prefix inet; 520 reference 521 "RFC 6991: Common YANG Data Types"; 522 } 524 import ietf-x509-cert-to-name { 525 prefix x509c2n; 526 reference 527 "RFC 7407: A YANG Data Model for SNMP Configuration"; 528 } 530 import ietf-tls-server { 531 prefix ts; 532 revision-date 2016-11-02; // stable grouping definitions 533 reference 534 "RFC ZZZZ: TLS Client and Server Models"; 535 } 537 organization 538 "IETF NETCONF (Network Configuration) Working Group"; 540 contact 541 "WG Web: 542 WG List: 544 WG Chair: Mehmet Ersue 545 547 WG Chair: Mahesh Jethanandani 548 550 Editor: Kent Watsen 551 "; 553 description 554 "This module contains a collection of YANG definitions for 555 configuring RESTCONF servers. 557 Copyright (c) 2014 IETF Trust and the persons identified as 558 authors of the code. All rights reserved. 560 Redistribution and use in source and binary forms, with or 561 without modification, is permitted pursuant to, and subject 562 to the license terms contained in, the Simplified BSD 563 License set forth in Section 4.c of the IETF Trust's 564 Legal Provisions Relating to IETF Documents 565 (http://trustee.ietf.org/license-info). 567 This version of this YANG module is part of RFC XXXX; see 568 the RFC itself for full legal notices."; 570 revision "2016-11-02" { 571 description 572 "Initial version"; 573 reference 574 "RFC XXXX: RESTCONF Client and Server Models"; 575 } 577 // Features 579 feature listen { 580 description 581 "The 'listen' feature indicates that the RESTCONF server 582 supports opening a port to accept RESTCONF client connections 583 using at least one transport (e.g., TLS, etc.)."; 584 } 586 feature tls-listen { 587 description 588 "The 'tls-listen' feature indicates that the RESTCONF server 589 supports opening a port to listen for incoming RESTCONF 590 client connections."; 591 reference 592 "RFC XXXX: RESTCONF Protocol"; 593 } 595 feature call-home { 596 description 597 "The 'call-home' feature indicates that the RESTCONF server 598 supports initiating RESTCONF call home connections to REETCONF 599 clients using at least one transport (e.g., TLS, etc.)."; 600 reference 601 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 602 } 604 feature tls-call-home { 605 description 606 "The 'tls-call-home' feature indicates that the RESTCONF server 607 supports initiating connections to RESTCONF clients."; 608 reference 609 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 610 } 612 feature client-cert-auth { 613 description 614 "The client-cert-auth feature indicates that the RESTCONF 615 server supports the ClientCertificate authentication scheme."; 616 reference 617 "RFC ZZZZ: Client Authentication over New TLS Connection"; 618 } 619 // top-level container 620 container restconf-server { 621 description 622 "Top-level container for RESTCONF server configuration."; 624 container listen { 625 if-feature listen; 626 description 627 "Configures listen behavior"; 628 leaf max-sessions { 629 type uint16; 630 default 0; // should this be 'max'? 631 description 632 "Specifies the maximum number of concurrent sessions 633 that can be active at one time. The value 0 indicates 634 that no artificial session limit should be used."; 635 } 636 list endpoint { 637 key name; 638 description 639 "List of endpoints to listen for RESTCONF connections on."; 640 leaf name { 641 type string; 642 description 643 "An arbitrary name for the RESTCONF listen endpoint."; 644 } 645 choice transport { 646 mandatory true; 647 description 648 "Selects between available transports."; 649 case tls { 650 if-feature tls-listen; 651 container tls { 652 description 653 "TLS-specific listening configuration for inbound 654 connections."; 655 uses ts:listening-tls-server-grouping { 656 refine port { 657 default 443; 658 } 659 augment "client-auth" { 660 description 661 "Augments in the cert-to-name structure."; 662 uses cert-maps-grouping; 663 } 664 } 665 } 666 } 668 } 669 } 670 } 672 container call-home { 673 if-feature call-home; 674 description 675 "Configures call-home behavior"; 676 list restconf-client { 677 key name; 678 description 679 "List of RESTCONF clients the RESTCONF server is to 680 initiate call-home connections to."; 681 leaf name { 682 type string; 683 description 684 "An arbitrary name for the remote RESTCONF client."; 685 } 686 choice transport { 687 mandatory true; 688 description 689 "Selects between TLS and any transports augmented in."; 690 case tls { 691 if-feature tls-call-home; 692 container tls { 693 description 694 "Specifies TLS-specific call-home transport 695 configuration."; 696 uses endpoints-container { 697 refine endpoints/endpoint/port { 698 default 4336; 699 } 700 } 701 uses ts:non-listening-tls-server-grouping { 702 augment "client-auth" { 703 description 704 "Augments in the cert-to-name structure."; 705 uses cert-maps-grouping; 706 } 707 } 708 } 709 } 710 } 711 container connection-type { 712 description 713 "Indicates the RESTCONF client's preference for how the 714 RESTCONF server's connection is maintained."; 715 choice connection-type { 716 description 717 "Selects between available connection types."; 718 case persistent-connection { 719 container persistent { 720 presence true; 721 description 722 "Maintain a persistent connection to the RESTCONF 723 client. If the connection goes down, immediately 724 start trying to reconnect to it, using the 725 reconnection strategy. 727 This connection type minimizes any RESTCONF client 728 to RESTCONF server data-transfer delay, albeit at 729 the expense of holding resources longer."; 731 container keep-alives { 732 description 733 "Configures the keep-alive policy, to proactively 734 test the aliveness of the TLS client. An 735 unresponsive TLS client will be dropped after 736 approximately (max-attempts * max-wait) 737 seconds."; 738 reference 739 "RFC YYYY: NETCONF Call Home and RESTCONF Call 740 Home, Section 3.1, item S6"; 741 leaf max-wait { 742 type uint16 { 743 range "1..max"; 744 } 745 units seconds; 746 default 30; 747 description 748 "Sets the amount of time in seconds after which 749 if no data has been received from the TLS 750 client, a TLS-level message will be sent to 751 test the aliveness of the TLS client."; 752 } 753 leaf max-attempts { 754 type uint8; 755 default 3; 756 description 757 "Sets the maximum number of sequential keep-alive 758 messages that can fail to obtain a response from 759 the TLS client before assuming the TLS client is 760 no longer alive."; 761 } 762 } 763 } 765 } 766 case periodic-connection { 767 container periodic { 768 presence true; 769 description 770 "Periodically connect to the RESTCONF client, so that 771 the RESTCONF client may deliver messages pending for 772 the RESTCONF server. The client must close the 773 connection when it's ready to release it. Once the 774 connection has been closed, the server will restart 775 its timer until the next connection."; 776 leaf reconnect-timeout { 777 type uint16 { 778 range "1..max"; 779 } 780 units minutes; 781 default 60; 782 description 783 "The maximum amount of unconnected time the 784 RESTCONF server will wait before re-establishing 785 a connection to the RESTCONF client. The 786 RESTCONF server may initiate a connection to 787 the RESTCONF client before this time if desired 788 (e.g., to deliver a notification)."; 789 } 790 } 791 } 792 } 793 } 794 container reconnect-strategy { 795 description 796 "The reconnection strategy directs how a RESTCONF server 797 reconnects to a RESTCONF client after after discovering 798 its connection to the client has dropped, even if due to 799 a reboot. The RESTCONF server starts with the specified 800 endpoint and tries to connect to it max-attempts times 801 before trying the next endpoint in the list (round 802 robin)."; 803 leaf start-with { 804 type enumeration { 805 enum first-listed { 806 description 807 "Indicates that reconnections should start with 808 the first endpoint listed."; 809 } 810 enum last-connected { 811 description 812 "Indicates that reconnections should start with 813 the endpoint last connected to. If no previous 814 connection has ever been established, then the 815 first endpoint configured is used. RESTCONF 816 servers SHOULD be able to remember the last 817 endpoint connected to across reboots."; 818 } 819 } 820 default first-listed; 821 description 822 "Specifies which of the RESTCONF client's endpoints the 823 RESTCONF server should start with when trying to connect 824 to the RESTCONF client."; 825 } 826 leaf max-attempts { 827 type uint8 { 828 range "1..max"; 829 } 830 default 3; 831 description 832 "Specifies the number times the RESTCONF server tries to 833 connect to a specific endpoint before moving on to the 834 next endpoint in the list (round robin)."; 835 } 836 } 837 } 838 } 839 } 841 grouping cert-maps-grouping { 842 description 843 "A grouping that defines a container around the 844 cert-to-name structure defined in RFC 7407."; 845 container cert-maps { 846 uses x509c2n:cert-to-name; 847 description 848 "The cert-maps container is used by a TLS-based RESTCONF 849 server to map the RESTCONF client's presented X.509 850 certificate to a RESTCONF username. If no matching and 851 valid cert-to-name list entry can be found, then the 852 RESTCONF server MUST close the connection, and MUST NOT 853 accept RESTCONF messages over it."; 854 reference 855 "RFC XXXX: The RESTCONF Protocol"; 856 } 857 } 858 grouping endpoints-container { 859 description 860 "This grouping is used by tls container for call-home 861 configurations."; 862 container endpoints { 863 description 864 "Container for the list of endpoints."; 865 list endpoint { 866 key name; 867 min-elements 1; 868 ordered-by user; 869 description 870 "User-ordered list of endpoints for this RESTCONF client. 871 Defining more than one enables high-availability."; 872 leaf name { 873 type string; 874 description 875 "An arbitrary name for this endpoint."; 876 } 877 leaf address { 878 type inet:host; 879 mandatory true; 880 description 881 "The IP address or hostname of the endpoint. If a 882 hostname is configured and the DNS resolution results 883 in more than one IP address, the RESTCONF server 884 will process the IP addresses as if they had been 885 explicitly configured in place of the hostname."; 886 } 887 leaf port { 888 type inet:port-number; 889 description 890 "The IP port for this endpoint. The RESTCONF server will 891 use the IANA-assigned well-known port if no value is 892 specified."; 893 } 894 } 895 } 896 } 898 } 900 902 4. Security Considerations 904 5. IANA Considerations 906 5.1. The IETF XML Registry 908 This document registers two URIs in the IETF XML registry [RFC2119]. 909 Following the format in [RFC3688], the following registrations are 910 requested: 912 URI: urn:ietf:params:xml:ns:yang:ietf-restconf-client 913 Registrant Contact: The NETCONF WG of the IETF. 914 XML: N/A, the requested URI is an XML namespace. 916 URI: urn:ietf:params:xml:ns:yang:ietf-restconf-server 917 Registrant Contact: The NETCONF WG of the IETF. 918 XML: N/A, the requested URI is an XML namespace. 920 5.2. The YANG Module Names Registry 922 This document registers two YANG modules in the YANG Module Names 923 registry [RFC6020]. Following the format in [RFC6020], the the 924 following registrations are requested: 926 name: ietf-restconf-client 927 namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-client 928 prefix: ncc 929 reference: RFC XXXX 931 name: ietf-restconf-server 932 namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server 933 prefix: ncs 934 reference: RFC XXXX 936 6. Acknowledgements 938 The authors would like to thank for following for lively discussions 939 on list and in the halls (ordered by last name): Andy Bierman, Martin 940 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 941 Ladislav Lhotka, Radek Krejci, Tom Petch, Phil Shafer, Sean Turner, 942 and Bert Wijnen. 944 Juergen Schoenwaelder and was partly funded by Flamingo, a Network of 945 Excellence project (ICT-318488) supported by the European Commission 946 under its Seventh Framework Programme. 948 7. References 950 7.1. Normative References 952 [draft-ietf-netconf-keystore] 953 Watsen, K., "Keystore Model", draft-ieft-netconf- 954 keystore-00 (work in progress), 2016, 955 . 958 [draft-ietf-netconf-restconf] 959 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 960 Protocol", draft-ieft-netconf-restconf-13 (work in 961 progress), 2016, . 964 [draft-ietf-netconf-tls-client-server] 965 Watsen, K., "TLS Client and Server Models", draft-ieft- 966 netconf-tls-client-server-00 (work in progress), 2016, 967 . 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, 972 DOI 10.17487/RFC2119, March 1997, 973 . 975 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 976 the Network Configuration Protocol (NETCONF)", RFC 6020, 977 DOI 10.17487/RFC6020, October 2010, 978 . 980 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 981 RFC 6991, DOI 10.17487/RFC6991, July 2013, 982 . 984 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 985 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 986 December 2014, . 988 7.2. Informative References 990 [draft-ietf-netconf-call-home] 991 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 992 draft-ieft-netconf-call-home-17 (work in progress), 2015, 993 . 996 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 997 DOI 10.17487/RFC3688, January 2004, 998 . 1000 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1001 (TLS) Protocol Version 1.2", RFC 5246, 1002 DOI 10.17487/RFC5246, August 2008, 1003 . 1005 Appendix A. Change Log 1007 A.1. server-model-09 to 00 1009 o This draft was split out from draft-ietf-netconf-server-model-09. 1011 o Added in new features 'listen' and 'call-home' so future 1012 transports can be augmented in. 1014 Appendix B. Open Issues 1016 Please see: https://github.com/netconf-wg/restconf-client-server/ 1017 issues. 1019 Authors' Addresses 1021 Kent Watsen 1022 Juniper Networks 1024 EMail: kwatsen@juniper.net 1026 Juergen Schoenwaelder 1027 Jacobs University Bremen 1029 EMail: j.schoenwaelder@jacobs-university.de