idnits 2.17.1
draft-ietf-netconf-tcp-client-server-04.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 196 has weird spacing: '...nterval uin...'
== Line 201 has weird spacing: '...nterval uin...'
== Line 370 has weird spacing: '...address ine...'
== Line 377 has weird spacing: '...nterval uin...'
== Line 560 has weird spacing: '...address ine...'
== (1 more instance...)
-- The document date (March 8, 2020) is 1509 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)
== Missing Reference: 'RFC1122' is mentioned on line 171, but not defined
== Missing Reference: 'RFC793bis' is mentioned on line 133, but not defined
** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293)
Summary: 1 error (**), 0 flaws (~~), 9 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: September 9, 2020 Hochschule Esslingen
6 March 8, 2020
8 YANG Groupings for TCP Clients and TCP Servers
9 draft-ietf-netconf-tcp-client-server-04
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 "2020-03-08" --> 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 September 9, 2020.
50 Copyright Notice
52 Copyright (c) 2020 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 Common Model . . . . . . . . . . . . . . . . . . . . 3
70 3.1. Model Scope . . . . . . . . . . . . . . . . . . . . . . . 3
71 3.2. Usage Guidelines for Configuring TCP Keep-Alives . . . . 3
72 3.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
73 3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5
74 3.5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5
75 4. The TCP Client Model . . . . . . . . . . . . . . . . . . . . 8
76 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8
77 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 9
78 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9
79 5. The TCP Server Model . . . . . . . . . . . . . . . . . . . . 12
80 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12
81 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13
82 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13
83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
85 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16
86 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
88 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
89 8.2. Informative References . . . . . . . . . . . . . . . . . 18
90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
91 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 19
92 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 19
93 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 19
94 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 19
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
97 1. Introduction
99 This document defines three YANG 1.1 [RFC7950] modules: the first
100 defines a grouping for configuring a generic TCP client, the second
101 defines a grouping for configuring a generic TCP server, and the
102 third defines a grouping common to the TCP clients and TCP servers.
104 It is intended that these groupings will be used either standalone,
105 for TCP-based protocols, as part of a stack of protocol-specific
106 configuration models. For instance, these groupings could help
107 define the configuration module for SSH, TLS, or HTTP based
108 applications.
110 2. Terminology
112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
114 "OPTIONAL" in this document are to be interpreted as described in BCP
115 14 [RFC2119] [RFC8174] when, and only when, they appear in all
116 capitals, as shown here.
118 3. The TCP Common Model
120 3.1. Model Scope
122 This document defines a common "grouping" statement for basic TCP
123 connection parameters that matter to applications. In some TCP
124 stacks, such parameters can also directly be set by an application
125 using system calls, such as the socket API. The base YANG model in
126 this document focuses on modeling TCP keep-alives. This base model
127 can be extended as needed.
129 3.2. Usage Guidelines for Configuring TCP Keep-Alives
131 Network stacks may include "keep-alives" in their TCP
132 implementations, although this practice is not universally accepted.
133 If keep-alives are included, [RFC1122] [RFC793bis] mandates that the
134 application MUST be able to turn them on or off for each TCP
135 connection, and that they MUST default to off.
137 Keep-alive mechanisms exist in many protocols. Depending on the
138 protocol stack, TCP keep-alives may only be one out of several
139 alternatives. Which mechanism to use depends on the use case and
140 application requirements. If keep-alives are needed by an
141 application, it is RECOMMENDED that the aliveness check happens at
142 the highest protocol layer possible that is meaningful to the
143 application, in order to maximize the depth of the aliveness check.
145 [[TODO: Further guidance on keep-alives is provided in draft-xyz-
146 tsvwg-... ]]
148 A TCP keep-alive mechanism should only be invoked in server
149 applications that might otherwise hang indefinitely and consume
150 resources unnecessarily if a client crashes or aborts a connection
151 during a network failure [RFC1122]. TCP keep-alives may consume
152 significant resources both in the network and in endpoints (e.g.,
153 battery power). In addition, frequent keep-alives risk network
154 congestion. The higher the frequency of keep-alives, the higher the
155 overhead.
157 Given the cost of keep-alives, parameters have to be configured
158 carefully:
160 o The default idle interval (leaf "idle-time") MUST default to no
161 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value
162 MAY be configured, but keep-alive messages SHOULD NOT be
163 transmitted more frequently than once every 15 seconds. Longer
164 intervals SHOULD be used when possible.
166 o The maximum number of sequential keep-alive probes that can fail
167 (leaf "max-probes") trades off responsiveness and robustness
168 against packet loss. ACK segments that contain no data are not
169 reliably transmitted by TCP. Consequently, if a keep-alive
170 mechanism is implemented it MUST NOT interpret failure to respond
171 to any specific probe as a dead connection [RFC1122]. Typically a
172 single-digit number should suffice.
174 o TCP implementations may include a parameter for the number of
175 seconds between TCP keep-alive probes (leaf "probe-interval"). In
176 order to avoid congestion, the time interval between probes MUST
177 NOT be smaller than one second. Significantly longer intervals
178 SHOULD be used. It is important to note that keep-alive probes
179 (or replies) can get dropped due to network congestion. Sending
180 further probe messages into a congested path after a short
181 interval, without backing off timers, could cause harm and result
182 in a congestion collapse. Therefore it is essential to pick a
183 large, conservative value for this interval.
185 3.3. Tree Diagram
187 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
188 common" module.
190 module: ietf-tcp-common
192 grouping tcp-common-grouping
193 +-- keepalives! {keepalives-supported}?
194 +-- idle-time uint16
195 +-- max-probes uint16
196 +-- probe-interval uint16
197 grouping tcp-connection-grouping
198 +-- keepalives! {keepalives-supported}?
199 +-- idle-time uint16
200 +-- max-probes uint16
201 +-- probe-interval uint16
203 3.4. Example Usage
205 This section presents an example showing the tcp-common-grouping
206 populated with some data.
208
209
210 15
211 3
212 30
213
214
216 3.5. YANG Module
218 The ietf-tcp-common YANG module references [RFC6991].
220 file "ietf-tcp-common@2020-03-08.yang"
222 module ietf-tcp-common {
223 yang-version 1.1;
224 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
225 prefix tcpcmn;
227 organization
228 "IETF NETCONF (Network Configuration) Working Group and the
229 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
231 contact
232 "WG Web:
233
234 WG List:
235
236 Authors: Kent Watsen
237 Michael Scharf
238 ";
240 description
241 "This module defines reusable groupings for TCP commons that
242 can be used as a basis for specific TCP common instances.
244 Copyright (c) 2019 IETF Trust and the persons identified
245 as authors of the code. All rights reserved.
247 Redistribution and use in source and binary forms, with
248 or without modification, is permitted pursuant to, and
249 subject to the license terms contained in, the Simplified
250 BSD License set forth in Section 4.c of the IETF Trust's
251 Legal Provisions Relating to IETF Documents
252 (https://trustee.ietf.org/license-info).
254 This version of this YANG module is part of RFC XXXX
255 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
256 itself for full legal notices.
258 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
259 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
260 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
261 are to be interpreted as described in BCP 14 (RFC 2119)
262 (RFC 8174) when, and only when, they appear in all
263 capitals, as shown here.";
265 revision 2020-03-08 {
266 description
267 "Initial version";
268 reference
269 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
270 }
272 // Features
273 feature keepalives-supported {
274 description
275 "Indicates that keepalives are supported.";
276 }
278 // Groupings
280 grouping tcp-common-grouping {
281 description
282 "A reusable grouping for configuring TCP parameters common
283 to TCP connections as well as the operating system as a
284 whole.";
285 container keepalives {
286 if-feature "keepalives-supported";
287 presence "Indicates that keepalives are enabled.";
288 description
289 "Configures the keep-alive policy, to proactively test the
290 aliveness of the TCP peer. An unresponsive TCP peer is
291 dropped after approximately (idle-time + max-probes
292 * probe-interval) seconds.";
293 leaf idle-time {
294 type uint16 {
295 range "1..max";
296 }
297 units "seconds";
298 mandatory true;
299 description
300 "Sets the amount of time after which if no data has been
301 received from the TCP peer, a TCP-level probe message
302 will be sent to test the aliveness of the TCP peer.
303 Two hours (7200 seconds) is safe value, per RFC 1122.";
304 reference
305 "RFC 1122:
306 Requirements for Internet Hosts -- Communication Layers";
307 }
308 leaf max-probes {
309 type uint16 {
310 range "1..max";
311 }
312 mandatory true;
313 description
314 "Sets the maximum number of sequential keep-alive probes
315 that can fail to obtain a response from the TCP peer
316 before assuming the TCP peer is no longer alive.";
317 }
318 leaf probe-interval {
319 type uint16 {
320 range "1..max";
321 }
322 units "seconds";
323 mandatory true;
324 description
325 "Sets the time interval between failed probes. The interval
326 SHOULD be significantly longer than one second in order to
327 avoid harm on a congested link.";
328 }
329 } // container keepalives
330 } // grouping tcp-common-grouping
332 grouping tcp-connection-grouping {
333 description
334 "A reusable grouping for configuring TCP parameters common
335 to TCP connections.";
336 uses tcp-common-grouping;
337 }
339 /*
340 The following is for a future bis...
341 This comment is here now so as support discussion with TCPM.
342 This comment will be removed before publication.
344 Should future system-level parameters be defined as a
345 grouping or a container?
347 grouping tcp-system-grouping {
348 description
349 "A reusable grouping for configuring TCP parameters common
350 to the operating system as a whole.";
352 // currently just a placeholder
353 }
354 */
356 }
358
360 4. The TCP Client Model
362 4.1. Tree Diagram
364 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
365 client" module.
367 module: ietf-tcp-client
369 grouping tcp-client-grouping
370 +-- remote-address inet:host
371 +-- remote-port? inet:port-number
372 +-- local-address? inet:ip-address {local-binding-supported}?
373 +-- local-port? inet:port-number {local-binding-supported}?
374 +-- keepalives! {keepalives-supported}?
375 +-- idle-time uint16
376 +-- max-probes uint16
377 +-- probe-interval uint16
379 4.2. Example Usage
381 This section presents an example showing the tcp-client-grouping
382 populated with some data.
384
385 www.example.com
386 443
387 0.0.0.0
388 0
389
390 15
391 3
392 30
393
394
396 4.3. YANG Module
398 The ietf-tcp-client YANG module references [RFC6991].
400 file "ietf-tcp-client@2020-03-08.yang"
402 module ietf-tcp-client {
403 yang-version 1.1;
404 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
405 prefix tcpc;
407 import ietf-inet-types {
408 prefix inet;
409 reference
410 "RFC 6991: Common YANG Data Types";
411 }
413 import ietf-tcp-common {
414 prefix tcpcmn;
415 reference
416 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
417 }
419 organization
420 "IETF NETCONF (Network Configuration) Working Group and the
421 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
423 contact
424 "WG Web:
425
426 WG List:
427
428 Authors: Kent Watsen
429 Michael Scharf
430 ";
432 description
433 "This module defines reusable groupings for TCP clients that
434 can be used as a basis for specific TCP client instances.
436 Copyright (c) 2019 IETF Trust and the persons identified
437 as authors of the code. All rights reserved.
439 Redistribution and use in source and binary forms, with
440 or without modification, is permitted pursuant to, and
441 subject to the license terms contained in, the Simplified
442 BSD License set forth in Section 4.c of the IETF Trust's
443 Legal Provisions Relating to IETF Documents
444 (https://trustee.ietf.org/license-info).
446 This version of this YANG module is part of RFC XXXX
447 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
448 itself for full legal notices.
450 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
451 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
452 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
453 are to be interpreted as described in BCP 14 (RFC 2119)
454 (RFC 8174) when, and only when, they appear in all
455 capitals, as shown here.";
457 revision 2020-03-08 {
458 description
459 "Initial version";
460 reference
461 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
462 }
464 // Features
466 feature local-binding-supported {
467 description
468 "Indicates that the server supports configuring local
469 bindings (i.e., the local address and local port) for
470 TCP clients.";
471 }
473 feature tcp-client-keepalives {
474 description
475 "Per socket TCP keepalive parameters are configurable for
476 TCP clients on the server implementing this feature.";
477 }
479 // Groupings
481 grouping tcp-client-grouping {
482 description
483 "A reusable grouping for configuring a TCP client.
485 Note that this grouping uses fairly typical descendent
486 node names such that a stack of 'uses' statements will
487 have name conflicts. It is intended that the consuming
488 data model will resolve the issue (e.g., by wrapping
489 the 'uses' statement in a container called
490 'tcp-client-parameters'). This model purposely does
491 not do this itself so as to provide maximum flexibility
492 to consuming models.";
494 leaf remote-address {
495 type inet:host;
496 mandatory true;
497 description
498 "The IP address or hostname of the remote peer to
499 establish a connection with. If a domain name is
500 configured, then the DNS resolution should happen on
501 each connection attempt. If the DNS resolution
502 results in multiple IP addresses, the IP addresses
503 are tried according to local preference order until
504 a connection has been established or until all IP
505 addresses have failed.";
506 }
507 leaf remote-port {
508 type inet:port-number;
509 default "0";
510 description
511 "The IP port number for the remote peer to establish a
512 connection with. An invalid default value (0) is used
513 (instead of 'mandatory true') so that as application
514 level data model may 'refine' it with an application
515 specific default port number value.";
516 }
517 leaf local-address {
518 if-feature "local-binding-supported";
519 type inet:ip-address;
520 description
521 "The local IP address/interface (VRF?) to bind to for when
522 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
523 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
524 explicitly indicate the implicit default, that the server
525 can bind to any IPv4 or IPv6 addresses, respectively.";
526 }
527 leaf local-port {
528 if-feature "local-binding-supported";
529 type inet:port-number;
530 default "0";
531 description
532 "The local IP port number to bind to for when connecting
533 to the remote peer. The port number '0', which is the
534 default value, indicates that any available local port
535 number may be used.";
536 }
537 uses tcpcmn:tcp-connection-grouping {
538 augment "keepalives" {
539 if-feature "tcp-client-keepalives";
540 description
541 "Add an if-feature statement so that implementations
542 can choose to support TCP client keepalives.";
543 }
544 }
545 }
546 }
548
550 5. The TCP Server Model
552 5.1. Tree Diagram
554 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
555 server" module.
557 module: ietf-tcp-server
559 grouping tcp-server-grouping
560 +-- local-address inet:ip-address
561 +-- local-port? inet:port-number
562 +-- keepalives! {keepalives-supported}?
563 +-- idle-time uint16
564 +-- max-probes uint16
565 +-- probe-interval uint16
567 5.2. Example Usage
569 This section presents an example showing the tcp-server-grouping
570 populated with some data.
572
573 10.20.30.40
574 7777
575
576 15
577 3
578 30
579
580
582 5.3. YANG Module
584 The ietf-tcp-server YANG module references [RFC6991].
586 file "ietf-tcp-server@2020-03-08.yang"
588 module ietf-tcp-server {
589 yang-version 1.1;
590 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
591 prefix tcps;
593 import ietf-inet-types {
594 prefix inet;
595 reference
596 "RFC 6991: Common YANG Data Types";
597 }
599 import ietf-tcp-common {
600 prefix tcpcmn;
601 reference
602 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
603 }
605 organization
606 "IETF NETCONF (Network Configuration) Working Group and the
607 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
609 contact
610 "WG Web:
611
612 WG List:
613
614 Authors: Kent Watsen
615 Michael Scharf
616 ";
618 description
619 "This module defines reusable groupings for TCP servers that
620 can be used as a basis for specific TCP server instances.
622 Copyright (c) 2019 IETF Trust and the persons identified
623 as authors of the code. All rights reserved.
625 Redistribution and use in source and binary forms, with
626 or without modification, is permitted pursuant to, and
627 subject to the license terms contained in, the Simplified
628 BSD License set forth in Section 4.c of the IETF Trust's
629 Legal Provisions Relating to IETF Documents
630 (https://trustee.ietf.org/license-info).
632 This version of this YANG module is part of RFC XXXX
633 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
634 itself for full legal notices.
636 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
637 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
638 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
639 are to be interpreted as described in BCP 14 (RFC 2119)
640 (RFC 8174) when, and only when, they appear in all
641 capitals, as shown here.";
643 revision 2020-03-08 {
644 description
645 "Initial version";
646 reference
647 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
648 }
650 // Features
652 feature tcp-server-keepalives {
653 description
654 "Per socket TCP keepalive parameters are configurable for
655 TCP servers on the server implementing this feature.";
656 }
658 // Groupings
660 grouping tcp-server-grouping {
661 description
662 "A reusable grouping for configuring a TCP server.
664 Note that this grouping uses fairly typical descendent
665 node names such that a stack of 'uses' statements will
666 have name conflicts. It is intended that the consuming
667 data model will resolve the issue (e.g., by wrapping
668 the 'uses' statement in a container called
669 'tcp-server-parameters'). This model purposely does
670 not do this itself so as to provide maximum flexibility
671 to consuming models.";
672 leaf local-address {
673 type inet:ip-address;
674 mandatory true;
675 description
676 "The local IP address to listen on for incoming
677 TCP client connections. INADDR_ANY (0.0.0.0) or
678 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
679 used when the server is to listen on all IPv4 or
680 IPv6 addresses, respectively.";
681 }
682 leaf local-port {
683 type inet:port-number;
684 default "0";
685 description
686 "The local port number to listen on for incoming TCP
687 client connections. An invalid default value (0)
688 is used (instead of 'mandatory true') so that an
689 application level data model may 'refine' it with
690 an application specific default port number value.";
691 }
692 uses tcpcmn:tcp-connection-grouping {
693 augment "keepalives" {
694 if-feature "tcp-server-keepalives";
695 description
696 "Add an if-feature statement so that implementations
697 can choose to support TCP server keepalives.";
698 }
699 }
700 }
701 }
703
705 6. Security Considerations
707 The YANG modules defined in this document are designed to be accessed
708 via YANG based management protocols, such as NETCONF [RFC6241] and
709 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
710 implement secure transport layers (e.g., SSH, TCP) with mutual
711 authentication.
713 The NETCONF access control model (NACM) [RFC8341] provides the means
714 to restrict access for particular users to a pre-configured subset of
715 all available protocol operations and content.
717 Since the modules defined in this document only define groupings,
718 these considerations are primarily for the designers of other modules
719 that use these groupings.
721 There are a number of data nodes defined in the YANG modules that are
722 writable/creatable/deletable (i.e., config true, which is the
723 default). These data nodes may be considered sensitive or vulnerable
724 in some network environments. Write operations (e.g., edit-config)
725 to these data nodes without proper protection can have a negative
726 effect on network operations. These are the subtrees and data nodes
727 and their sensitivity/vulnerability:
729 None of the writable/creatable/deletable data nodes in
730 the YANG modules defined in this document are considered more
731 sensitive or vulnerable then standard configuration.
733 Some of the readable data nodes in the YANG modules may be considered
734 sensitive or vulnerable in some network environments. It is thus
735 important to control read access (e.g., via get, get-config, or
736 notification) to these data nodes. These are the subtrees and data
737 nodes and their sensitivity/vulnerability:
739 None of the readable data nodes in the YANG modules
740 defined in this document are considered more sensitive or vulnerable
741 then standard configuration.
743 This document does not define any RPC actions and hence this section
744 does not consider the security of RPCs.
746 7. IANA Considerations
748 7.1. The IETF XML Registry
750 This document registers two URIs in the "ns" subregistry of the IETF
751 XML Registry [RFC3688]. Following the format in [RFC3688], the
752 following registrations are requested:
754 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
755 Registrant Contact: The NETCONF WG of the IETF.
756 XML: N/A, the requested URI is an XML namespace.
758 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
759 Registrant Contact: The NETCONF WG of the IETF.
760 XML: N/A, the requested URI is an XML namespace.
762 7.2. The YANG Module Names Registry
764 This document registers two YANG modules in the YANG Module Names
765 registry [RFC6020]. Following the format in [RFC6020], the following
766 registrations are requested:
768 name: ietf-tcp-common
769 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
770 prefix: tcpcmn
771 reference: RFC XXXX
773 name: ietf-tcp-client
774 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
775 prefix: tcpc
776 reference: RFC XXXX
778 name: ietf-tcp-server
779 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
780 prefix: tcps
781 reference: RFC XXXX
783 8. References
785 8.1. Normative References
787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
788 Requirement Levels", BCP 14, RFC 2119,
789 DOI 10.17487/RFC2119, March 1997,
790 .
792 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
793 the Network Configuration Protocol (NETCONF)", RFC 6020,
794 DOI 10.17487/RFC6020, October 2010,
795 .
797 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
798 RFC 6991, DOI 10.17487/RFC6991, July 2013,
799 .
801 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
802 RFC 7950, DOI 10.17487/RFC7950, August 2016,
803 .
805 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
806 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
807 May 2017, .
809 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
810 Access Control Model", STD 91, RFC 8341,
811 DOI 10.17487/RFC8341, March 2018,
812 .
814 8.2. Informative References
816 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
817 DOI 10.17487/RFC3688, January 2004,
818 .
820 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
821 and A. Bierman, Ed., "Network Configuration Protocol
822 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
823 .
825 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
826 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
827 .
829 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
830 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
831 .
833 Appendix A. Change Log
835 A.1. 00 to 01
837 o Added 'local-binding-supported' feature to TCP-client model.
839 o Added 'keepalives-supported' feature to TCP-common model.
841 o Added 'external-endpoint-values' container and 'external-
842 endpoints' feature to TCP-server model.
844 A.2. 01 to 02
846 o Removed the 'external-endpoint-values' container and 'external-
847 endpoints' feature from the TCP-server model.
849 A.3. 02 to 03
851 o Moved the common model section to be before the client and server
852 specific sections.
854 o Added sections "Model Scope" and "Usage Guidelines for Configuring
855 TCP Keep-Alives" to the common model section.
857 A.4. 03 to 04
859 o Fixed a few typos.
861 Authors' Addresses
863 Kent Watsen
864 Watsen Networks
866 EMail: kent+ietf@watsen.net
868 Michael Scharf
869 Hochschule Esslingen - University of Applied Sciences
871 EMail: michael.scharf@hs-esslingen.de