idnits 2.17.1 draft-ietf-netconf-tcp-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 123 has weird spacing: '...address ine...' == Line 130 has weird spacing: '...nterval uin...' == Line 315 has weird spacing: '...nterval uin...' == Line 317 has weird spacing: '...address ine...' == Line 510 has weird spacing: '...nterval uin...' == (1 more instance...) -- The document date (June 7, 2019) is 1778 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track M. Scharf 5 Expires: December 9, 2019 Hochschule Esslingen 6 June 7, 2019 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-01 11 Abstract 13 This document defines three YANG modules: the first defines a 14 grouping for configuring a generic TCP client, the second defines a 15 grouping for configuring a generic TCP server, and the third defines 16 a grouping common to the TCP clients and TCP servers. 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 Artwork in this document contains placeholder values for the date of 26 publication of this draft. Please apply the following replacement: 28 o "2019-06-07" --> the publication date of this draft 30 The following Appendix section is to be removed prior to publication: 32 o Appendix A. Change Log 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 9, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. The TCP Client Model . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 3 72 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. The TCP Server Model . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. The TCP Common Model . . . . . . . . . . . . . . . . . . . . 11 78 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 11 79 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 80 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 84 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 16 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 8.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 89 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 This document defines three YANG 1.1 [RFC7950] modules: the first 95 defines a grouping for configuring a generic TCP client, the second 96 defines a grouping for configuring a generic TCP server, and the 97 third defines a grouping common to the TCP clients and TCP servers. 99 It is intended that these groupings will be used either standalone, 100 for TCP-based protocols, as part of a stack of protocol-specific 101 configuration models. For instance, these groupings could help 102 define the configuration module for SSH, TLS, or HTTP based 103 applications. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 3. The TCP Client Model 115 3.1. Tree Diagram 117 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 118 client" module. 120 module: ietf-tcp-client 122 grouping tcp-client-grouping 123 +-- remote-address inet:host 124 +-- remote-port? inet:port-number 125 +-- local-address? inet:ip-address {local-binding-supported}? 126 +-- local-port? inet:port-number {local-binding-supported}? 127 +-- keepalives! {keepalives-supported}? 128 +-- idle-time uint16 129 +-- max-probes uint16 130 +-- probe-interval uint16 132 3.2. Example Usage 134 This section presents an example showing the tcp-client-grouping 135 populated with some data. 137 138 www.example.com 139 443 140 0.0.0.0 141 0 142 143 15 144 3 145 30 146 147 149 3.3. YANG Module 151 The ietf-tcp-client YANG module references [RFC6991]. 153 file "ietf-tcp-client@2019-06-07.yang" 154 module ietf-tcp-client { 155 yang-version 1.1; 156 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 157 prefix tcpc; 159 import ietf-inet-types { 160 prefix inet; 161 reference 162 "RFC 6991: Common YANG Data Types"; 163 } 165 import ietf-tcp-common { 166 prefix tcpcmn; 167 reference 168 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 169 } 171 organization 172 "IETF NETCONF (Network Configuration) Working Group and the 173 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 175 contact 176 "WG Web: 177 178 WG List: 179 180 Authors: Kent Watsen 181 Michael Scharf 182 "; 184 description 185 "This module defines reusable groupings for TCP clients that 186 can be used as a basis for specific TCP client instances. 188 Copyright (c) 2019 IETF Trust and the persons identified 189 as authors of the code. All rights reserved. 191 Redistribution and use in source and binary forms, with 192 or without modification, is permitted pursuant to, and 193 subject to the license terms contained in, the Simplified 194 BSD License set forth in Section 4.c of the IETF Trust's 195 Legal Provisions Relating to IETF Documents 196 (https://trustee.ietf.org/license-info). 198 This version of this YANG module is part of RFC XXXX 199 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 200 itself for full legal notices.; 202 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 203 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 204 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 205 are to be interpreted as described in BCP 14 (RFC 2119) 206 (RFC 8174) when, and only when, they appear in all 207 capitals, as shown here."; 209 revision 2019-06-07 { 210 description 211 "Initial version"; 212 reference 213 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 214 } 216 // Features 218 feature local-binding-supported { 219 description 220 "Indicates that the server supports configuring local bindings, 221 the 'local-address' and 'local-port' nodes."; 222 } 224 feature tcp-client-keepalives { 225 description 226 "Per socket TCP keepalive parameters are configurable for 227 TCP clients on the server implementing this feature."; 228 } 230 // Groupings 232 grouping tcp-client-grouping { 233 description 234 "A reusable grouping for configuring a TCP client. 236 Note that this grouping uses fairly typical descendent 237 node names such that a stack of 'uses' statements will 238 have name conflicts. It is intended that the consuming 239 data model will resolve the issue (e.g., by wrapping 240 the 'uses' statement in a container called 241 'tcp-client-parameters'). This model purposely does 242 not do this itself so as to provide maximum flexibility 243 to consuming models."; 245 leaf remote-address { 246 type inet:host; 247 mandatory true; 248 description 249 "The IP address or hostname of the remote peer to 250 establish a connection with. If a domain name is 251 configured, then the DNS resolution should happen on 252 each connection attempt. If the the DNS resolution 253 results in multiple IP addresses, the IP addresses 254 are tried according to local preference order until 255 a connection has been established or until all IP 256 addresses have failed."; 257 } 258 leaf remote-port { 259 type inet:port-number; 260 default "0"; 261 description 262 "The IP port number for the remote peer to establish a 263 connection with. An invalid default value (0) is used 264 (instead of 'mandatory true') so that as application 265 level data model may 'refine' it with an application 266 specific default port number value."; 267 } 268 leaf local-address { 269 if-feature "local-binding-supported"; 270 type inet:ip-address; 271 description 272 "The local IP address/interface (VRF?) to bind to for when 273 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 274 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 275 explicitly indicate the implicit default, that the server 276 can bind to any IPv4 or IPv6 addresses, respectively."; 277 } 278 leaf local-port { 279 if-feature "local-binding-supported"; 280 type inet:port-number; 281 default "0"; 282 description 283 "The local IP port number to bind to for when connecting 284 to the remote peer. The port number '0', which is the 285 default value, indicates that any available local port 286 number may be used."; 287 } 288 uses tcpcmn:tcp-connection-grouping { 289 augment "keepalives" { 290 if-feature "tcp-client-keepalives"; 291 description 292 "Add an if-feature statement so that implementations 293 can choose to support TCP client keepalives."; 294 } 295 } 296 } 297 } 298 300 4. The TCP Server Model 302 4.1. Tree Diagram 304 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 305 server" module. 307 module: ietf-tcp-server 309 grouping tcp-server-grouping 310 +-- local-address inet:ip-address 311 +-- local-port? inet:port-number 312 +-- keepalives! {keepalives-supported}? 313 | +-- idle-time uint16 314 | +-- max-probes uint16 315 | +-- probe-interval uint16 316 +-- external-endpoint-values! {external-endpoints}? 317 +-- address inet:ip-address 318 +-- port? inet:port-number 320 4.2. Example Usage 322 This section presents an example showing the tcp-server-grouping 323 populated with some data. 325 326 10.20.30.40 327 7777 328 329 15 330 3 331 30 332 333 335 4.3. YANG Module 337 The ietf-tcp-server YANG module references [RFC6991]. 339 file "ietf-tcp-server@2019-06-07.yang" 340 module ietf-tcp-server { 341 yang-version 1.1; 342 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 343 prefix tcps; 345 import ietf-inet-types { 346 prefix inet; 347 reference 348 "RFC 6991: Common YANG Data Types"; 349 } 351 import ietf-tcp-common { 352 prefix tcpcmn; 353 reference 354 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 355 } 357 organization 358 "IETF NETCONF (Network Configuration) Working Group and the 359 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 361 contact 362 "WG Web: 363 364 WG List: 365 366 Authors: Kent Watsen 367 Michael Scharf 368 "; 370 description 371 "This module defines reusable groupings for TCP servers that 372 can be used as a basis for specific TCP server instances. 374 Copyright (c) 2019 IETF Trust and the persons identified 375 as authors of the code. All rights reserved. 377 Redistribution and use in source and binary forms, with 378 or without modification, is permitted pursuant to, and 379 subject to the license terms contained in, the Simplified 380 BSD License set forth in Section 4.c of the IETF Trust's 381 Legal Provisions Relating to IETF Documents 382 (https://trustee.ietf.org/license-info). 384 This version of this YANG module is part of RFC XXXX 385 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 386 itself for full legal notices.; 388 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 389 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 390 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 391 are to be interpreted as described in BCP 14 (RFC 2119) 392 (RFC 8174) when, and only when, they appear in all 393 capitals, as shown here."; 395 revision 2019-06-07 { 396 description 397 "Initial version"; 398 reference 399 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 400 } 402 // Features 404 feature tcp-server-keepalives { 405 description 406 "Per socket TCP keepalive parameters are configurable for 407 TCP servers on the server implementing this feature."; 408 } 410 feature external-endpoints { 411 description 412 "Per socket TCP keepalive parameters are configurable for 413 TCP servers on the server implementing this feature."; 414 } 416 // Groupings 418 grouping tcp-server-grouping { 419 description 420 "A reusable grouping for configuring a TCP server. 422 Note that this grouping uses fairly typical descendent 423 node names such that a stack of 'uses' statements will 424 have name conflicts. It is intended that the consuming 425 data model will resolve the issue (e.g., by wrapping 426 the 'uses' statement in a container called 427 'tcp-server-parameters'). This model purposely does 428 not do this itself so as to provide maximum flexibility 429 to consuming models."; 430 leaf local-address { 431 type inet:ip-address; 432 mandatory true; 433 description 434 "The local IP address to listen on for incoming 435 TCP client connections. INADDR_ANY (0.0.0.0) or 436 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 437 used when the server is to listen on all IPv4 or 438 IPv6 addresses, respectively."; 439 } 440 leaf local-port { 441 type inet:port-number; 442 default "0"; 443 description 444 "The local port number to listen on for incoming TCP 445 client connections. An invalid default value (0) 446 is used (instead of 'mandatory true') so that an 447 application level data model may 'refine' it with 448 an application specific default port number value."; 449 } 450 uses tcpcmn:tcp-connection-grouping { 451 augment "keepalives" { 452 if-feature "tcp-server-keepalives"; 453 description 454 "Add an if-feature statement so that implementations 455 can choose to support TCP server keepalives."; 456 } 457 } 458 container external-endpoint-values { 459 if-feature external-endpoints; 460 presence 461 "Indicates that external endpoint values are configured."; 462 description 463 "External endpoint values described the values used by 464 an external system that terminates connections before 465 passing them onto server. Such systems may include, 466 e.g., a network address translator (NAT) or a load 467 balancer (LB). 469 These values have no effect on the local operation of 470 this server, but MAY be used by the application when 471 sending messages including response contact information 472 (e.g., URL)."; 473 leaf address { 474 type inet:ip-address; 475 mandatory true; 476 description 477 "The external IP address used to listen for incoming 478 TCP client connections that are forwarded to this 479 server."; 480 } 481 leaf port { 482 type inet:port-number; 483 default "0"; 484 description 485 "The external port number used to listen for incoming 486 TCP client connections that are forwarded to this 487 server. An invalid default value (0) is used (instead 488 of 'mandatory true') so that an application level data 489 model may 'refine' it with an application specific 490 default port number value."; 491 } 492 } 493 } 494 } 495 497 5. The TCP Common Model 499 5.1. Tree Diagram 501 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 502 common" module. 504 module: ietf-tcp-common 506 grouping tcp-common-grouping 507 +-- keepalives! {keepalives-supported}? 508 +-- idle-time uint16 509 +-- max-probes uint16 510 +-- probe-interval uint16 511 grouping tcp-connection-grouping 512 +-- keepalives! {keepalives-supported}? 513 +-- idle-time uint16 514 +-- max-probes uint16 515 +-- probe-interval uint16 517 5.2. Example Usage 519 This section presents an example showing the tcp-common-grouping 520 populated with some data. 522 523 524 15 525 3 526 30 527 528 530 5.3. YANG Module 532 The ietf-tcp-common YANG module references [RFC6991]. 534 file "ietf-tcp-common@2019-06-07.yang" 535 module ietf-tcp-common { 536 yang-version 1.1; 537 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 538 prefix tcpcmn; 540 organization 541 "IETF NETCONF (Network Configuration) Working Group and the 542 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 544 contact 545 "WG Web: 546 547 WG List: 548 549 Authors: Kent Watsen 550 Michael Scharf 551 "; 553 description 554 "This module defines reusable groupings for TCP commons that 555 can be used as a basis for specific TCP common instances. 557 Copyright (c) 2019 IETF Trust and the persons identified 558 as authors of the code. All rights reserved. 560 Redistribution and use in source and binary forms, with 561 or without modification, is permitted pursuant to, and 562 subject to the license terms contained in, the Simplified 563 BSD License set forth in Section 4.c of the IETF Trust's 564 Legal Provisions Relating to IETF Documents 565 (https://trustee.ietf.org/license-info). 567 This version of this YANG module is part of RFC XXXX 568 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 569 itself for full legal notices.; 571 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 572 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 573 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 574 are to be interpreted as described in BCP 14 (RFC 2119) 575 (RFC 8174) when, and only when, they appear in all 576 capitals, as shown here."; 578 revision 2019-06-07 { 579 description 580 "Initial version"; 581 reference 582 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 583 } 585 // Features 586 feature keepalives-supported { 587 description 588 "Indicates that keepalives are supported."; 589 } 591 // Groupings 593 grouping tcp-common-grouping { 594 description 595 "A reusable grouping for configuring TCP parameters common 596 to TCP connections as well as the operating system as a 597 whole."; 598 container keepalives { 599 if-feature "keepalives-supported"; 600 presence "Indicates that keepalives are enabled."; 601 description 602 "Configures the keep-alive policy, to proactively test the 603 aliveness of the TCP peer. An unresponsive TCP peer is 604 dropped after approximately (idle-time * 60) + (max-probes 605 * probe-interval) seconds."; 606 leaf idle-time { 607 type uint16 { 608 range "1..max"; 609 } 610 units "seconds"; 611 mandatory true; 612 description 613 "Sets the amount of time after which if no data has been 614 received from the TCP peer, a TCP-level probe message 615 will be sent to test the aliveness of the TCP peer."; 616 } 617 leaf max-probes { 618 type uint16 { 619 range "1..max"; 620 } 621 mandatory true; 622 description 623 "Sets the maximum number of sequential keep-alive probes 624 that can fail to obtain a response from the TCP peer 625 before assuming the TCP peer is no longer alive."; 626 } 627 leaf probe-interval { 628 type uint16 { 629 range "1..max"; 630 } 631 units "seconds"; 632 mandatory true; 633 description 634 "Sets the time interval between failed probes."; 635 } 636 } // container keepalives 637 } // grouping tcp-common-grouping 639 grouping tcp-connection-grouping { 640 description 641 "A reusable grouping for configuring TCP parameters common 642 to TCP connections."; 643 uses tcp-common-grouping; 644 } 646 /* 647 The following is for a future bis... 648 This comment is here now so as support discussion with TCPM. 649 This comment will be removed before publication. 651 Should future system-level parameters be defined as a 652 grouping or a container? 654 grouping tcp-system-grouping { 655 description 656 "A reusable grouping for configuring TCP parameters common 657 to the operating system as a whole."; 659 // currently just a placeholder 661 } 662 */ 664 } 665 667 6. Security Considerations 669 The YANG modules defined in this document are designed to be accessed 670 via YANG based management protocols, such as NETCONF [RFC6241] and 671 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 672 implement secure transport layers (e.g., SSH, TCP) with mutual 673 authentication. 675 The NETCONF access control model (NACM) [RFC8341] provides the means 676 to restrict access for particular users to a pre-configured subset of 677 all available protocol operations and content. 679 Since the modules defined in this document only define groupings, 680 these considerations are primarily for the designers of other modules 681 that use these groupings. 683 There are a number of data nodes defined in the YANG modules that are 684 writable/creatable/deletable (i.e., config true, which is the 685 default). These data nodes may be considered sensitive or vulnerable 686 in some network environments. Write operations (e.g., edit-config) 687 to these data nodes without proper protection can have a negative 688 effect on network operations. These are the subtrees and data nodes 689 and their sensitivity/vulnerability: 691 None of the writable/creatable/deletable data nodes in 692 the YANG modules defined in this document are considered more 693 sensitive or vulnerable then standard configuration. 695 Some of the readable data nodes in the YANG modules may be considered 696 sensitive or vulnerable in some network environments. It is thus 697 important to control read access (e.g., via get, get-config, or 698 notification) to these data nodes. These are the subtrees and data 699 nodes and their sensitivity/vulnerability: 701 None of the readable data nodes in the YANG modules 702 defined in this document are considered more sensitive or vulnerable 703 then standard configuration. 705 This document does not define any RPC actions and hence this section 706 does not consider the security of RPCs. 708 7. IANA Considerations 710 7.1. The IETF XML Registry 712 This document registers two URIs in the "ns" subregistry of the IETF 713 XML Registry [RFC3688]. Following the format in [RFC3688], the 714 following registrations are requested: 716 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 717 Registrant Contact: The NETCONF WG of the IETF. 718 XML: N/A, the requested URI is an XML namespace. 720 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 721 Registrant Contact: The NETCONF WG of the IETF. 722 XML: N/A, the requested URI is an XML namespace. 724 7.2. The YANG Module Names Registry 726 This document registers two YANG modules in the YANG Module Names 727 registry [RFC6020]. Following the format in [RFC6020], the following 728 registrations are requested: 730 name: ietf-tcp-common 731 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 732 prefix: tcpcmn 733 reference: RFC XXXX 735 name: ietf-tcp-client 736 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 737 prefix: tcpc 738 reference: RFC XXXX 740 name: ietf-tcp-server 741 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 742 prefix: tcps 743 reference: RFC XXXX 745 8. References 747 8.1. Normative References 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 755 the Network Configuration Protocol (NETCONF)", RFC 6020, 756 DOI 10.17487/RFC6020, October 2010, 757 . 759 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 760 RFC 6991, DOI 10.17487/RFC6991, July 2013, 761 . 763 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 764 RFC 7950, DOI 10.17487/RFC7950, August 2016, 765 . 767 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 768 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 769 May 2017, . 771 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 772 Access Control Model", STD 91, RFC 8341, 773 DOI 10.17487/RFC8341, March 2018, 774 . 776 8.2. Informative References 778 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 779 DOI 10.17487/RFC3688, January 2004, 780 . 782 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 783 and A. Bierman, Ed., "Network Configuration Protocol 784 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 785 . 787 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 788 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 789 . 791 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 792 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 793 . 795 Appendix A. Change Log 797 A.1. 00 to 01 799 o Added 'local-binding-supported' feature to TCP-client model. 801 o Added 'keepalives-supported' feature to TCP-common model. 803 o Added 'external-endpoint-values' container and 'external- 804 endpoints' feature to TCP-server model. 806 Authors' Addresses 808 Kent Watsen 809 Watsen Networks 811 EMail: kent+ietf@watsen.net 813 Michael Scharf 814 Hochschule Esslingen - University of Applied Sciences 816 EMail: michael.scharf@hs-esslingen.de