idnits 2.17.1
draft-ietf-netconf-tcp-client-server-03.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 195 has weird spacing: '...nterval uin...'
== Line 200 has weird spacing: '...nterval uin...'
== Line 369 has weird spacing: '...address ine...'
== Line 376 has weird spacing: '...nterval uin...'
== Line 559 has weird spacing: '...address ine...'
== (1 more instance...)
-- The document date (October 18, 2019) is 1645 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 170, but not defined
== Missing Reference: 'RFC793bis' is mentioned on line 132, 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: April 20, 2020 Hochschule Esslingen
6 October 18, 2019
8 YANG Groupings for TCP Clients and TCP Servers
9 draft-ietf-netconf-tcp-client-server-03
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-10-18" --> 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 April 20, 2020.
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 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
96 1. Introduction
98 This document defines three YANG 1.1 [RFC7950] modules: the first
99 defines a grouping for configuring a generic TCP client, the second
100 defines a grouping for configuring a generic TCP server, and the
101 third defines a grouping common to the TCP clients and TCP servers.
103 It is intended that these groupings will be used either standalone,
104 for TCP-based protocols, as part of a stack of protocol-specific
105 configuration models. For instance, these groupings could help
106 define the configuration module for SSH, TLS, or HTTP based
107 applications.
109 2. Terminology
111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
113 "OPTIONAL" in this document are to be interpreted as described in BCP
114 14 [RFC2119] [RFC8174] when, and only when, they appear in all
115 capitals, as shown here.
117 3. The TCP Common Model
119 3.1. Model Scope
121 This document defines a common "grouping" statement for basic TCP
122 connection parameters that matter to applications. In some TCP
123 stacks, such parameters can also directly be set by an application
124 using system calls, such as the socket API. The base YANG model in
125 this document focuses on modeling TCP keep-alives. This base model
126 can be extended as needed.
128 3.2. Usage Guidelines for Configuring TCP Keep-Alives
130 Network stacks may include "keep-alives" in their TCP
131 implementations, although this practice is not universally accepted.
132 If keep-alives are included, [RFC1122] [RFC793bis] mandates that the
133 application MUST be able to turn them on or off for each TCP
134 connection, and that they MUST default to off.
136 Keep-alive mechanisms exist in many protocols. Depending on the
137 protocol stack, TCP keep-alives may only be one out of several
138 alternatives. Which mechanism to use depends on the use case and
139 application requirements. If keep-alives are needed by an
140 application, it is RECOMMENDED that the aliveness check happens at
141 the highest protocol layer possible that is meaningful to the
142 application, in order to maximize the depth of the aliveness check.
144 [[TODO: Further guidance on keep-alives is provided in draft-xyz-
145 tsvwg-... ]]
147 A TCP keep-alive mechanism should only be invoked in server
148 applications that might otherwise hang indefinitely and consume
149 resources unnecessarily if a client crashes or aborts a connection
150 during a network failure [RFC1122]. TCP keep-alives may consume
151 significant resources both in the network and in endpoints (e.g.,
152 battery power). In addition, frequent keep-alives risk network
153 congestion. The higher the frequency of keep-alives, the higher the
154 overhead.
156 Given the cost of keep-alives, parameters have to be configured
157 carefully:
159 o The default idle interval (leaf "idle-time") MUST default to no
160 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value
161 MAY be configured, but keep-alive messages SHOULD NOT be
162 transmitted more frequently than once every 15 seconds. Longer
163 intervals SHOULD be used when possible.
165 o The maximum number of sequential keep-alive probes that can fail
166 (leaf "max-probes") trades off responsiveness and robustness
167 against packet loss. ACK segments that contain no data are not
168 reliably transmitted by TCP. Consequently, if a keep-alive
169 mechanism is implemented it MUST NOT interpret failure to respond
170 to any specific probe as a dead connection [RFC1122]. Typically a
171 single-digit number should suffice.
173 o TCP implementations may include a parameter for the number of
174 seconds between TCP keep-alive probes (leaf "probe-interval"). In
175 order to avoid congestion, the time interval between probes MUST
176 NOT be smaller than one second. Significantly longer intervals
177 SHOULD be used. It is important to note that keep-alive probes
178 (or replies) can get dropped due to network congestion. Sending
179 further probe messages into a congested path after a short
180 interval, without backing off timers, could cause harm and result
181 in a congestion collapse. Therefore it is essential to pick a
182 large, conservative value for this interval.
184 3.3. Tree Diagram
186 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
187 common" module.
189 module: ietf-tcp-common
191 grouping tcp-common-grouping
192 +-- keepalives! {keepalives-supported}?
193 +-- idle-time uint16
194 +-- max-probes uint16
195 +-- probe-interval uint16
196 grouping tcp-connection-grouping
197 +-- keepalives! {keepalives-supported}?
198 +-- idle-time uint16
199 +-- max-probes uint16
200 +-- probe-interval uint16
202 3.4. Example Usage
204 This section presents an example showing the tcp-common-grouping
205 populated with some data.
207
208
209 15
210 3
211 30
212
213
215 3.5. YANG Module
217 The ietf-tcp-common YANG module references [RFC6991].
219 file "ietf-tcp-common@2019-10-18.yang"
221 module ietf-tcp-common {
222 yang-version 1.1;
223 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
224 prefix tcpcmn;
226 organization
227 "IETF NETCONF (Network Configuration) Working Group and the
228 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
230 contact
231 "WG Web:
232
233 WG List:
234
235 Authors: Kent Watsen
236 Michael Scharf
237 ";
239 description
240 "This module defines reusable groupings for TCP commons that
241 can be used as a basis for specific TCP common instances.
243 Copyright (c) 2019 IETF Trust and the persons identified
244 as authors of the code. All rights reserved.
246 Redistribution and use in source and binary forms, with
247 or without modification, is permitted pursuant to, and
248 subject to the license terms contained in, the Simplified
249 BSD License set forth in Section 4.c of the IETF Trust's
250 Legal Provisions Relating to IETF Documents
251 (https://trustee.ietf.org/license-info).
253 This version of this YANG module is part of RFC XXXX
254 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
255 itself for full legal notices.;
257 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
258 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
259 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
260 are to be interpreted as described in BCP 14 (RFC 2119)
261 (RFC 8174) when, and only when, they appear in all
262 capitals, as shown here.";
264 revision 2019-10-18 {
265 description
266 "Initial version";
267 reference
268 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
269 }
271 // Features
272 feature keepalives-supported {
273 description
274 "Indicates that keepalives are supported.";
275 }
277 // Groupings
279 grouping tcp-common-grouping {
280 description
281 "A reusable grouping for configuring TCP parameters common
282 to TCP connections as well as the operating system as a
283 whole.";
284 container keepalives {
285 if-feature "keepalives-supported";
286 presence "Indicates that keepalives are enabled.";
287 description
288 "Configures the keep-alive policy, to proactively test the
289 aliveness of the TCP peer. An unresponsive TCP peer is
290 dropped after approximately (idle-time + max-probes
291 * probe-interval) seconds.";
292 leaf idle-time {
293 type uint16 {
294 range "1..max";
295 }
296 units "seconds";
297 mandatory true;
298 description
299 "Sets the amount of time after which if no data has been
300 received from the TCP peer, a TCP-level probe message
301 will be sent to test the aliveness of the TCP peer.
302 Two hours (7200 seconds) is safe value, per RFC 1122.";
303 reference
304 "RFC 1122:
305 Requirements for Internet Hosts -- Communication Layers";
306 }
307 leaf max-probes {
308 type uint16 {
309 range "1..max";
310 }
311 mandatory true;
312 description
313 "Sets the maximum number of sequential keep-alive probes
314 that can fail to obtain a response from the TCP peer
315 before assuming the TCP peer is no longer alive.";
316 }
317 leaf probe-interval {
318 type uint16 {
319 range "1..max";
320 }
321 units "seconds";
322 mandatory true;
323 description
324 "Sets the time interval between failed probes. The interval
325 SHOULD be significantly longer than one second in order to
326 avoid harm on a congested link.";
327 }
328 } // container keepalives
329 } // grouping tcp-common-grouping
331 grouping tcp-connection-grouping {
332 description
333 "A reusable grouping for configuring TCP parameters common
334 to TCP connections.";
335 uses tcp-common-grouping;
336 }
338 /*
339 The following is for a future bis...
340 This comment is here now so as support discussion with TCPM.
341 This comment will be removed before publication.
343 Should future system-level parameters be defined as a
344 grouping or a container?
346 grouping tcp-system-grouping {
347 description
348 "A reusable grouping for configuring TCP parameters common
349 to the operating system as a whole.";
351 // currently just a placeholder
352 }
353 */
355 }
357
359 4. The TCP Client Model
361 4.1. Tree Diagram
363 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
364 client" module.
366 module: ietf-tcp-client
368 grouping tcp-client-grouping
369 +-- remote-address inet:host
370 +-- remote-port? inet:port-number
371 +-- local-address? inet:ip-address {local-binding-supported}?
372 +-- local-port? inet:port-number {local-binding-supported}?
373 +-- keepalives! {keepalives-supported}?
374 +-- idle-time uint16
375 +-- max-probes uint16
376 +-- probe-interval uint16
378 4.2. Example Usage
380 This section presents an example showing the tcp-client-grouping
381 populated with some data.
383
384 www.example.com
385 443
386 0.0.0.0
387 0
388
389 15
390 3
391 30
392
393
395 4.3. YANG Module
397 The ietf-tcp-client YANG module references [RFC6991].
399 file "ietf-tcp-client@2019-10-18.yang"
401 module ietf-tcp-client {
402 yang-version 1.1;
403 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
404 prefix tcpc;
406 import ietf-inet-types {
407 prefix inet;
408 reference
409 "RFC 6991: Common YANG Data Types";
410 }
412 import ietf-tcp-common {
413 prefix tcpcmn;
414 reference
415 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
416 }
418 organization
419 "IETF NETCONF (Network Configuration) Working Group and the
420 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
422 contact
423 "WG Web:
424
425 WG List:
426
427 Authors: Kent Watsen
428 Michael Scharf
429 ";
431 description
432 "This module defines reusable groupings for TCP clients that
433 can be used as a basis for specific TCP client instances.
435 Copyright (c) 2019 IETF Trust and the persons identified
436 as authors of the code. All rights reserved.
438 Redistribution and use in source and binary forms, with
439 or without modification, is permitted pursuant to, and
440 subject to the license terms contained in, the Simplified
441 BSD License set forth in Section 4.c of the IETF Trust's
442 Legal Provisions Relating to IETF Documents
443 (https://trustee.ietf.org/license-info).
445 This version of this YANG module is part of RFC XXXX
446 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
447 itself for full legal notices.;
449 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
450 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
451 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
452 are to be interpreted as described in BCP 14 (RFC 2119)
453 (RFC 8174) when, and only when, they appear in all
454 capitals, as shown here.";
456 revision 2019-10-18 {
457 description
458 "Initial version";
459 reference
460 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
461 }
463 // Features
465 feature local-binding-supported {
466 description
467 "Indicates that the server supports configuring local
468 bindings (i.e., the local address and local port) for
469 TCP clients.";
470 }
472 feature tcp-client-keepalives {
473 description
474 "Per socket TCP keepalive parameters are configurable for
475 TCP clients on the server implementing this feature.";
476 }
478 // Groupings
480 grouping tcp-client-grouping {
481 description
482 "A reusable grouping for configuring a TCP client.
484 Note that this grouping uses fairly typical descendent
485 node names such that a stack of 'uses' statements will
486 have name conflicts. It is intended that the consuming
487 data model will resolve the issue (e.g., by wrapping
488 the 'uses' statement in a container called
489 'tcp-client-parameters'). This model purposely does
490 not do this itself so as to provide maximum flexibility
491 to consuming models.";
493 leaf remote-address {
494 type inet:host;
495 mandatory true;
496 description
497 "The IP address or hostname of the remote peer to
498 establish a connection with. If a domain name is
499 configured, then the DNS resolution should happen on
500 each connection attempt. If the DNS resolution
501 results in multiple IP addresses, the IP addresses
502 are tried according to local preference order until
503 a connection has been established or until all IP
504 addresses have failed.";
505 }
506 leaf remote-port {
507 type inet:port-number;
508 default "0";
509 description
510 "The IP port number for the remote peer to establish a
511 connection with. An invalid default value (0) is used
512 (instead of 'mandatory true') so that as application
513 level data model may 'refine' it with an application
514 specific default port number value.";
515 }
516 leaf local-address {
517 if-feature "local-binding-supported";
518 type inet:ip-address;
519 description
520 "The local IP address/interface (VRF?) to bind to for when
521 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
522 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
523 explicitly indicate the implicit default, that the server
524 can bind to any IPv4 or IPv6 addresses, respectively.";
525 }
526 leaf local-port {
527 if-feature "local-binding-supported";
528 type inet:port-number;
529 default "0";
530 description
531 "The local IP port number to bind to for when connecting
532 to the remote peer. The port number '0', which is the
533 default value, indicates that any available local port
534 number may be used.";
535 }
536 uses tcpcmn:tcp-connection-grouping {
537 augment "keepalives" {
538 if-feature "tcp-client-keepalives";
539 description
540 "Add an if-feature statement so that implementations
541 can choose to support TCP client keepalives.";
542 }
543 }
544 }
545 }
547
549 5. The TCP Server Model
551 5.1. Tree Diagram
553 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
554 server" module.
556 module: ietf-tcp-server
558 grouping tcp-server-grouping
559 +-- local-address inet:ip-address
560 +-- local-port? inet:port-number
561 +-- keepalives! {keepalives-supported}?
562 +-- idle-time uint16
563 +-- max-probes uint16
564 +-- probe-interval uint16
566 5.2. Example Usage
568 This section presents an example showing the tcp-server-grouping
569 populated with some data.
571
572 10.20.30.40
573 7777
574
575 15
576 3
577 30
578
579
581 5.3. YANG Module
583 The ietf-tcp-server YANG module references [RFC6991].
585 file "ietf-tcp-server@2019-10-18.yang"
587 module ietf-tcp-server {
588 yang-version 1.1;
589 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
590 prefix tcps;
592 import ietf-inet-types {
593 prefix inet;
594 reference
595 "RFC 6991: Common YANG Data Types";
596 }
598 import ietf-tcp-common {
599 prefix tcpcmn;
600 reference
601 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
602 }
604 organization
605 "IETF NETCONF (Network Configuration) Working Group and the
606 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
608 contact
609 "WG Web:
610
611 WG List:
612
613 Authors: Kent Watsen
614 Michael Scharf
615 ";
617 description
618 "This module defines reusable groupings for TCP servers that
619 can be used as a basis for specific TCP server instances.
621 Copyright (c) 2019 IETF Trust and the persons identified
622 as authors of the code. All rights reserved.
624 Redistribution and use in source and binary forms, with
625 or without modification, is permitted pursuant to, and
626 subject to the license terms contained in, the Simplified
627 BSD License set forth in Section 4.c of the IETF Trust's
628 Legal Provisions Relating to IETF Documents
629 (https://trustee.ietf.org/license-info).
631 This version of this YANG module is part of RFC XXXX
632 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
633 itself for full legal notices.;
635 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
636 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
637 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
638 are to be interpreted as described in BCP 14 (RFC 2119)
639 (RFC 8174) when, and only when, they appear in all
640 capitals, as shown here.";
642 revision 2019-10-18 {
643 description
644 "Initial version";
645 reference
646 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
647 }
649 // Features
651 feature tcp-server-keepalives {
652 description
653 "Per socket TCP keepalive parameters are configurable for
654 TCP servers on the server implementing this feature.";
655 }
657 // Groupings
659 grouping tcp-server-grouping {
660 description
661 "A reusable grouping for configuring a TCP server.
663 Note that this grouping uses fairly typical descendent
664 node names such that a stack of 'uses' statements will
665 have name conflicts. It is intended that the consuming
666 data model will resolve the issue (e.g., by wrapping
667 the 'uses' statement in a container called
668 'tcp-server-parameters'). This model purposely does
669 not do this itself so as to provide maximum flexibility
670 to consuming models.";
671 leaf local-address {
672 type inet:ip-address;
673 mandatory true;
674 description
675 "The local IP address to listen on for incoming
676 TCP client connections. INADDR_ANY (0.0.0.0) or
677 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
678 used when the server is to listen on all IPv4 or
679 IPv6 addresses, respectively.";
680 }
681 leaf local-port {
682 type inet:port-number;
683 default "0";
684 description
685 "The local port number to listen on for incoming TCP
686 client connections. An invalid default value (0)
687 is used (instead of 'mandatory true') so that an
688 application level data model may 'refine' it with
689 an application specific default port number value.";
690 }
691 uses tcpcmn:tcp-connection-grouping {
692 augment "keepalives" {
693 if-feature "tcp-server-keepalives";
694 description
695 "Add an if-feature statement so that implementations
696 can choose to support TCP server keepalives.";
697 }
698 }
699 }
700 }
702
704 6. Security Considerations
706 The YANG modules defined in this document are designed to be accessed
707 via YANG based management protocols, such as NETCONF [RFC6241] and
708 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
709 implement secure transport layers (e.g., SSH, TCP) with mutual
710 authentication.
712 The NETCONF access control model (NACM) [RFC8341] provides the means
713 to restrict access for particular users to a pre-configured subset of
714 all available protocol operations and content.
716 Since the modules defined in this document only define groupings,
717 these considerations are primarily for the designers of other modules
718 that use these groupings.
720 There are a number of data nodes defined in the YANG modules that are
721 writable/creatable/deletable (i.e., config true, which is the
722 default). These data nodes may be considered sensitive or vulnerable
723 in some network environments. Write operations (e.g., edit-config)
724 to these data nodes without proper protection can have a negative
725 effect on network operations. These are the subtrees and data nodes
726 and their sensitivity/vulnerability:
728 None of the writable/creatable/deletable data nodes in
729 the YANG modules defined in this document are considered more
730 sensitive or vulnerable then standard configuration.
732 Some of the readable data nodes in the YANG modules may be considered
733 sensitive or vulnerable in some network environments. It is thus
734 important to control read access (e.g., via get, get-config, or
735 notification) to these data nodes. These are the subtrees and data
736 nodes and their sensitivity/vulnerability:
738 None of the readable data nodes in the YANG modules
739 defined in this document are considered more sensitive or vulnerable
740 then standard configuration.
742 This document does not define any RPC actions and hence this section
743 does not consider the security of RPCs.
745 7. IANA Considerations
747 7.1. The IETF XML Registry
749 This document registers two URIs in the "ns" subregistry of the IETF
750 XML Registry [RFC3688]. Following the format in [RFC3688], the
751 following registrations are requested:
753 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
754 Registrant Contact: The NETCONF WG of the IETF.
755 XML: N/A, the requested URI is an XML namespace.
757 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
758 Registrant Contact: The NETCONF WG of the IETF.
759 XML: N/A, the requested URI is an XML namespace.
761 7.2. The YANG Module Names Registry
763 This document registers two YANG modules in the YANG Module Names
764 registry [RFC6020]. Following the format in [RFC6020], the following
765 registrations are requested:
767 name: ietf-tcp-common
768 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
769 prefix: tcpcmn
770 reference: RFC XXXX
772 name: ietf-tcp-client
773 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
774 prefix: tcpc
775 reference: RFC XXXX
777 name: ietf-tcp-server
778 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
779 prefix: tcps
780 reference: RFC XXXX
782 8. References
784 8.1. Normative References
786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
787 Requirement Levels", BCP 14, RFC 2119,
788 DOI 10.17487/RFC2119, March 1997,
789 .
791 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
792 the Network Configuration Protocol (NETCONF)", RFC 6020,
793 DOI 10.17487/RFC6020, October 2010,
794 .
796 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
797 RFC 6991, DOI 10.17487/RFC6991, July 2013,
798 .
800 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
801 RFC 7950, DOI 10.17487/RFC7950, August 2016,
802 .
804 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
805 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
806 May 2017, .
808 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
809 Access Control Model", STD 91, RFC 8341,
810 DOI 10.17487/RFC8341, March 2018,
811 .
813 8.2. Informative References
815 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
816 DOI 10.17487/RFC3688, January 2004,
817 .
819 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
820 and A. Bierman, Ed., "Network Configuration Protocol
821 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
822 .
824 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
825 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
826 .
828 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
829 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
830 .
832 Appendix A. Change Log
834 A.1. 00 to 01
836 o Added 'local-binding-supported' feature to TCP-client model.
838 o Added 'keepalives-supported' feature to TCP-common model.
840 o Added 'external-endpoint-values' container and 'external-
841 endpoints' feature to TCP-server model.
843 A.2. 01 to 02
845 o Removed the 'external-endpoint-values' container and 'external-
846 endpoints' feature from the TCP-server model.
848 A.3. 02 to 03
850 o Moved the common model section to be before the client and server
851 specific sections.
853 o Added sections "Model Scope" and "Usage Guidelines for Configuring
854 TCP Keep-Alives" to the common model section.
856 Authors' Addresses
858 Kent Watsen
859 Watsen Networks
861 EMail: kent+ietf@watsen.net
863 Michael Scharf
864 Hochschule Esslingen - University of Applied Sciences
866 EMail: michael.scharf@hs-esslingen.de