idnits 2.17.1
draft-ietf-netconf-tcp-client-server-08.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 :
----------------------------------------------------------------------------
** The abstract seems to contain references ([RFC7950]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 248 has weird spacing: '...nterval uin...'
== Line 417 has weird spacing: '...is node must ...'
== Line 528 has weird spacing: '...address ine...'
== Line 532 has weird spacing: '...address ine...'
-- The document date (20 August 2020) is 1342 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 316, but not defined
== Missing Reference: 'RFC793bis' is mentioned on line 282, but not defined
** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293)
== Outdated reference: A later version (-34) exists of
draft-ietf-netconf-crypto-types-17
== Outdated reference: A later version (-20) exists of
draft-ietf-netconf-http-client-server-04
== Outdated reference: A later version (-35) exists of
draft-ietf-netconf-keystore-19
== Outdated reference: A later version (-36) exists of
draft-ietf-netconf-netconf-client-server-20
== Outdated reference: A later version (-36) exists of
draft-ietf-netconf-restconf-client-server-20
== Outdated reference: A later version (-40) exists of
draft-ietf-netconf-ssh-client-server-21
== Outdated reference: A later version (-26) exists of
draft-ietf-netconf-tcp-client-server-07
== Outdated reference: A later version (-41) exists of
draft-ietf-netconf-tls-client-server-21
== Outdated reference: A later version (-28) exists of
draft-ietf-netconf-trust-anchors-12
Summary: 2 errors (**), 0 flaws (~~), 16 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: 21 February 2021 Hochschule Esslingen
6 20 August 2020
8 YANG Groupings for TCP Clients and TCP Servers
9 draft-ietf-netconf-tcp-client-server-08
11 Abstract
13 This document defines three YANG 1.1 [RFC7950] modules to support the
14 configuration of TCP clients and TCP servers, either as standalone or
15 in conjunction with a stack protocol layer specific configurations.
17 Editorial Note (To be removed by RFC Editor)
19 This draft contains placeholder values that need to be replaced with
20 finalized values at the time of publication. This note summarizes
21 all of the substitutions that are needed. No other RFC Editor
22 instructions are specified elsewhere in this document.
24 Artwork in this document contains shorthand references to drafts in
25 progress. Please apply the following replacements:
27 * "DDDD" --> the assigned RFC value for this draft
29 Artwork in this document contains placeholder values for the date of
30 publication of this draft. Please apply the following replacement:
32 * "2020-08-20" --> the publication date of this draft
34 The following Appendix section is to be removed prior to publication:
36 * Appendix A. Change Log
38 Status of This Memo
40 This Internet-Draft is submitted in full conformance with the
41 provisions of BCP 78 and BCP 79.
43 Internet-Drafts are working documents of the Internet Engineering
44 Task Force (IETF). Note that other groups may also distribute
45 working documents as Internet-Drafts. The list of current Internet-
46 Drafts is at https://datatracker.ietf.org/drafts/current/.
48 Internet-Drafts are draft documents valid for a maximum of six months
49 and may be updated, replaced, or obsoleted by other documents at any
50 time. It is inappropriate to use Internet-Drafts as reference
51 material or to cite them other than as "work in progress."
53 This Internet-Draft will expire on 21 February 2021.
55 Copyright Notice
57 Copyright (c) 2020 IETF Trust and the persons identified as the
58 document authors. All rights reserved.
60 This document is subject to BCP 78 and the IETF Trust's Legal
61 Provisions Relating to IETF Documents (https://trustee.ietf.org/
62 license-info) in effect on the date of publication of this document.
63 Please review these documents carefully, as they describe your rights
64 and restrictions with respect to this document. Code Components
65 extracted from this document must include Simplified BSD License text
66 as described in Section 4.e of the Trust Legal Provisions and are
67 provided without warranty as described in the Simplified BSD License.
69 Table of Contents
71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
72 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3
73 1.2. Specification Language . . . . . . . . . . . . . . . . . 5
74 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5
75 2. The "ietf-tcp-common" Module . . . . . . . . . . . . . . . . 5
76 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5
77 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8
78 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
79 3. The "ietf-tcp-client" Module . . . . . . . . . . . . . . . . 11
80 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 11
81 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13
82 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14
83 4. The "ietf-tcp-server" Module . . . . . . . . . . . . . . . . 21
84 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 21
85 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 22
86 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23
87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
88 5.1. The "ietf-tcp-common" YANG Module . . . . . . . . . . . . 25
89 5.2. The "ietf-tcp-client" YANG Module . . . . . . . . . . . . 26
90 5.3. The "ietf-tcp-server" YANG Module . . . . . . . . . . . . 27
91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
92 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 27
93 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 28
94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
95 7.1. Normative References . . . . . . . . . . . . . . . . . . 28
96 7.2. Informative References . . . . . . . . . . . . . . . . . 29
97 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31
98 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 31
99 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 31
100 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 31
101 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 31
102 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 31
103 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 31
104 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 32
105 A.8. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 32
106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
108 1. Introduction
110 This document defines three YANG 1.1 [RFC7950] modules to support the
111 configuration of TCP clients and TCP servers, either as standalone or
112 in conjunction with a stack protocol layer specific configurations.
114 1.1. Relation to other RFCs
116 This document presents one or more YANG modules [RFC7950] that are
117 part of a collection of RFCs that work together to define
118 configuration modules for clients and servers of both the NETCONF
119 [RFC6241] and RESTCONF [RFC8040] protocols.
121 The modules have been defined in a modular fashion to enable their
122 use by other efforts, some of which are known to be in progress at
123 the time of this writing, with many more expected to be defined in
124 time.
126 The normative dependency relationship between the various RFCs in the
127 collection is presented in the below diagram. The labels in the
128 diagram represent the primary purpose provided by each RFC.
129 Hyperlinks to each RFC are provided below the diagram.
131 crypto-types
132 ^ ^
133 / \
134 / \
135 truststore keystore
136 ^ ^ ^ ^
137 | +---------+ | |
138 | | | |
139 | +------------+ |
140 tcp-client-server | / | |
141 ^ ^ ssh-client-server | |
142 | | ^ tls-client-server
143 | | | ^ ^ http-client-server
144 | | | | | ^
145 | | | +-----+ +---------+ |
146 | | | | | |
147 | +-----------|--------|--------------+ | |
148 | | | | | |
149 +-----------+ | | | | |
150 | | | | | |
151 | | | | | |
152 netconf-client-server restconf-client-server
154 +=======================+===========================================+
155 | Label in Diagram | Originating RFC |
156 +=======================+===========================================+
157 | crypto-types | [I-D.ietf-netconf-crypto-types] |
158 +-----------------------+-------------------------------------------+
159 | truststore | [I-D.ietf-netconf-trust-anchors] |
160 +-----------------------+-------------------------------------------+
161 | keystore | [I-D.ietf-netconf-keystore] |
162 +-----------------------+-------------------------------------------+
163 | tcp-client-server | [I-D.ietf-netconf-tcp-client-server] |
164 +-----------------------+-------------------------------------------+
165 | ssh-client-server | [I-D.ietf-netconf-ssh-client-server] |
166 +-----------------------+-------------------------------------------+
167 | tls-client-server | [I-D.ietf-netconf-tls-client-server] |
168 +-----------------------+-------------------------------------------+
169 | http-client-server | [I-D.ietf-netconf-http-client-server] |
170 +-----------------------+-------------------------------------------+
171 | netconf-client-server | [I-D.ietf-netconf-netconf-client-server] |
172 +-----------------------+-------------------------------------------+
173 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] |
174 +-----------------------+-------------------------------------------+
176 Table 1: Label to RFC Mapping
178 1.2. Specification Language
180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
182 "OPTIONAL" in this document are to be interpreted as described in BCP
183 14 [RFC2119] [RFC8174] when, and only when, they appear in all
184 capitals, as shown here.
186 1.3. Adherence to the NMDA
188 This document in compliant with the Network Management Datastore
189 Architecture (NMDA) [RFC8342]. It does not define any protocol
190 accessible nodes that are "config false".
192 2. The "ietf-tcp-common" Module
194 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp-
195 common". A high-level overview of the module is provided in
196 Section 2.1. Examples illustatrating the module's use are provided
197 in Examples (Section 2.2). The YANG module itself is defined in
198 Section 2.3.
200 2.1. Data Model Overview
202 This section provides an overview of the "ietf-tcp-common" module in
203 terms of its features and groupings.
205 2.1.1. Model Scope
207 This document defines a common "grouping" statement for basic TCP
208 connection parameters that matter to applications. In some TCP
209 stacks, such parameters can also directly be set by an application
210 using system calls, such as the socket API. The base YANG model in
211 this document focuses on modeling TCP keep-alives. This base model
212 can be extended as needed.
214 2.1.2. Features
216 The following diagram lists all the "feature" statements defined in
217 the "ietf-tcp-common" module:
219 Features:
220 +-- keepalives-supported
222 | The diagram above uses syntax that is similar to but not
223 | defined in [RFC8340].
225 2.1.3. Groupings
227 The following diagram lists all the "grouping" statements defined in
228 the "ietf-keystore" module:
230 Groupings:
231 +-- tcp-common-grouping
232 +-- tcp-connection-grouping
234 | The diagram above uses syntax that is similar to but not
235 | defined in [RFC8340].
237 Each of these groupings are presented in the following subsections.
239 2.1.3.1. The "tcp-common-grouping" Grouping
241 The following tree diagram [RFC8340] illustrates the "tcp-common-
242 grouping" grouping:
244 grouping tcp-common-grouping
245 +-- keepalives! {keepalives-supported}?
246 +-- idle-time uint16
247 +-- max-probes uint16
248 +-- probe-interval uint16
250 Comments:
252 * The "keepalives" node is a "presence" node so that the decendent
253 nodes' "mandatory true" doesn't imply that keepalives must be
254 configured.
256 * The "idle-time", "max-probes", and "probe-interval" nodes have the
257 common meanings. Please see the YANG module in Section 2.3 for
258 details.
260 2.1.3.2. The "tcp-connection-grouping" Grouping
262 The following tree diagram [RFC8340] illustrates the "tcp-connection-
263 grouping" grouping:
265 grouping tcp-connection-grouping
266 +---u tcp-common-grouping
268 Comments:
270 * This grouping uses the "tcp-common-grouping" grouping discussed in
271 Section 2.1.3.1.
273 2.1.4. Protocol-accessible Nodes
275 The "ietf-tcp-common" module does not contain any protocol-accessible
276 nodes.
278 2.1.5. Guidelines for Configuring TCP Keep-Alives
280 Network stacks may include "keep-alives" in their TCP
281 implementations, although this practice is not universally accepted.
282 If keep-alives are included, [RFC1122] [RFC793bis] mandates that the
283 application MUST be able to turn them on or off for each TCP
284 connection, and that they MUST default to off.
286 Keep-alive mechanisms exist in many protocols. Depending on the
287 protocol stack, TCP keep-alives may only be one out of several
288 alternatives. Which mechanism(s) to use depends on the use case and
289 application requirements. If keep-alives are needed by an
290 application, it is RECOMMENDED that the aliveness check happens only
291 at the protocol layers that are meaningful to the application.
293 A TCP keep-alive mechanism SHOULD only be invoked in server
294 applications that might otherwise hang indefinitely and consume
295 resources unnecessarily if a client crashes or aborts a connection
296 during a network failure [RFC1122]. TCP keep-alives may consume
297 significant resources both in the network and in endpoints (e.g.,
298 battery power). In addition, frequent keep-alives risk network
299 congestion. The higher the frequency of keep-alives, the higher the
300 overhead.
302 Given the cost of keep-alives, parameters have to be configured
303 carefully:
305 * The default idle interval (leaf "idle-time") MUST default to no
306 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value
307 MAY be configured, but keep-alive messages SHOULD NOT be
308 transmitted more frequently than once every 15 seconds. Longer
309 intervals SHOULD be used when possible.
311 * The maximum number of sequential keep-alive probes that can fail
312 (leaf "max-probes") trades off responsiveness and robustness
313 against packet loss. ACK segments that contain no data are not
314 reliably transmitted by TCP. Consequently, if a keep-alive
315 mechanism is implemented it MUST NOT interpret failure to respond
316 to any specific probe as a dead connection [RFC1122]. Typically a
317 single-digit number should suffice.
319 * TCP implementations may include a parameter for the number of
320 seconds between TCP keep-alive probes (leaf "probe-interval"). In
321 order to avoid congestion, the time interval between probes MUST
322 NOT be smaller than one second. Significantly longer intervals
323 SHOULD be used. It is important to note that keep-alive probes
324 (or replies) can get dropped due to network congestion. Sending
325 further probe messages into a congested path after a short
326 interval, without backing off timers, could cause harm and result
327 in a congestion collapse. Therefore it is essential to pick a
328 large, conservative value for this interval.
330 2.2. Example Usage
332 This section presents an example showing the "tcp-common-grouping"
333 populated with some data.
335
336
337 15
338 3
339 30
340
341
343 2.3. YANG Module
345 The ietf-tcp-common YANG module references [RFC6991].
347 file "ietf-tcp-common@2020-08-20.yang"
349 module ietf-tcp-common {
350 yang-version 1.1;
351 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
352 prefix tcpcmn;
354 organization
355 "IETF NETCONF (Network Configuration) Working Group and the
356 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
358 contact
359 "WG Web:
360
361 WG List:
362
363 Authors: Kent Watsen
364 Michael Scharf
365 ";
367 description
368 "This module defines reusable groupings for TCP commons that
369 can be used as a basis for specific TCP common instances.
371 Copyright (c) 2020 IETF Trust and the persons identified
372 as authors of the code. All rights reserved.
374 Redistribution and use in source and binary forms, with
375 or without modification, is permitted pursuant to, and
376 subject to the license terms contained in, the Simplified
377 BSD License set forth in Section 4.c of the IETF Trust's
378 Legal Provisions Relating to IETF Documents
379 (https://trustee.ietf.org/license-info).
381 This version of this YANG module is part of RFC DDDD
382 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
383 itself for full legal notices.
385 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
386 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
387 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
388 are to be interpreted as described in BCP 14 (RFC 2119)
389 (RFC 8174) when, and only when, they appear in all
390 capitals, as shown here.";
392 revision 2020-08-20 {
393 description
394 "Initial version";
395 reference
396 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
397 }
399 // Features
400 feature keepalives-supported {
401 description
402 "Indicates that keepalives are supported.";
403 }
405 // Groupings
407 grouping tcp-common-grouping {
408 description
409 "A reusable grouping for configuring TCP parameters common
410 to TCP connections as well as the operating system as a
411 whole.";
412 container keepalives {
413 if-feature "keepalives-supported";
414 presence
415 "Indicates that keepalives are enabled. Present so that
416 the decendant nodes' 'mandatory true' doesn't imply that
417 this node must be configured.";
418 description
419 "Configures the keep-alive policy, to proactively test the
420 aliveness of the TCP peer. An unresponsive TCP peer is
421 dropped after approximately (idle-time + max-probes
422 * probe-interval) seconds.";
423 leaf idle-time {
424 type uint16 {
425 range "1..max";
426 }
427 units "seconds";
428 mandatory true;
429 description
430 "Sets the amount of time after which if no data has been
431 received from the TCP peer, a TCP-level probe message
432 will be sent to test the aliveness of the TCP peer.
433 Two hours (7200 seconds) is safe value, per RFC 1122.";
434 reference
435 "RFC 1122:
436 Requirements for Internet Hosts -- Communication Layers";
437 }
438 leaf max-probes {
439 type uint16 {
440 range "1..max";
441 }
442 mandatory true;
443 description
444 "Sets the maximum number of sequential keep-alive probes
445 that can fail to obtain a response from the TCP peer
446 before assuming the TCP peer is no longer alive.";
447 }
448 leaf probe-interval {
449 type uint16 {
450 range "1..max";
451 }
452 units "seconds";
453 mandatory true;
454 description
455 "Sets the time interval between failed probes. The interval
456 SHOULD be significantly longer than one second in order to
457 avoid harm on a congested link.";
458 }
459 } // container keepalives
460 } // grouping tcp-common-grouping
461 grouping tcp-connection-grouping {
462 description
463 "A reusable grouping for configuring TCP parameters common
464 to TCP connections.";
465 uses tcp-common-grouping;
466 }
468 }
470
472 3. The "ietf-tcp-client" Module
474 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp-
475 client". A high-level overview of the module is provided in
476 Section 3.1. Examples illustatrating the module's use are provided
477 in Examples (Section 3.2). The YANG module itself is defined in
478 Section 3.3.
480 3.1. Data Model Overview
482 This section provides an overview of the "ietf-tcp-client" module in
483 terms of its features and groupings.
485 3.1.1. Features
487 The following diagram lists all the "feature" statements defined in
488 the "ietf-tcp-client" module:
490 Features:
491 +-- local-binding-supported
492 +-- tcp-client-keepalives
493 +-- proxy-connect
494 +-- socks5-gss-api
495 +-- socks5-username-password
497 | The diagram above uses syntax that is similar to but not
498 | defined in [RFC8340].
500 3.1.2. Groupings
502 The following diagram lists all the "grouping" statements defined in
503 the "ietf-tcp-client" module:
505 Groupings:
506 +-- tcp-client-grouping
507 | The diagram above uses syntax that is similar to but not
508 | defined in [RFC8340].
510 Each of these groupings are presented in the following subsections.
512 3.1.2.1. The "tcp-client-grouping" Grouping
514 The following tree diagram [RFC8340] illustrates the "tcp-client-
515 grouping" grouping:
517 grouping tcp-client-grouping
518 +-- remote-address inet:host
519 +-- remote-port? inet:port-number
520 +-- local-address? inet:ip-address
521 | {local-binding-supported}?
522 +-- local-port? inet:port-number
523 | {local-binding-supported}?
524 +-- proxy-server! {proxy-connect}?
525 | +-- (proxy-type)
526 | +--:(socks4)
527 | | +-- socks4-parameters
528 | | +-- remote-address inet:ip-address
529 | | +-- remote-port? inet:port-number
530 | +--:(socks4a)
531 | | +-- socks4a-parameters
532 | | +-- remote-address inet:host
533 | | +-- remote-port? inet:port-number
534 | +--:(socks5)
535 | +-- socks5-parameters
536 | +-- remote-address inet:host
537 | +-- remote-port? inet:port-number
538 | +-- authentication-parameters!
539 | +-- (auth-type)
540 | +--:(gss-api) {socks5-gss-api}?
541 | | +-- gss-api
542 | +--:(username-password)
543 | {socks5-username-password}?
544 | +-- username-password
545 | +-- username string
546 | +---u ct:password-grouping
547 +---u tcpcmn:tcp-connection-grouping
549 Comments:
551 * The "remote-address" node, which is mandatory, may be configured
552 as an IPv4 address, an IPv6 address, a hostname.
554 * The "remote-port" node is not mandatory, but its default value is
555 the invalid value '0', thus forcing the consuming data model to
556 refine it in order to provide it an appropriate default value.
558 * The "local-address" node, which is enabled by the "local-binding-
559 supported" feature (Section 2.1.2), may be configured as an IPv4
560 address, an IPv6 address, or a wildcard value.
562 * The "local-port" node, which is enabled by the "local-binding-
563 supported" feature (Section 2.1.2), is not mandatory. Its default
564 value is '0', indicating that the operating system can pick an
565 arbitrary port number.
567 * The "proxy-server" node is enabled by a "feature" statement and,
568 for servers that enable it, is a "presence" container so that the
569 decendent "mandatory true" choice node doesn't imply that the
570 proxt-server node must be configured.
572 * This grouping uses the "tcp-connection-grouping" grouping
573 discussed in Section 2.1.3.2.
575 3.1.3. Protocol-accessible Nodes
577 The "ietf-tcp-client" module does not contain any protocol-accessible
578 nodes.
580 3.2. Example Usage
582 This section presents two examples showing the "tcp-client-grouping"
583 populated with some data. This example shows a TCP-client configured
584 to not connect via a proxy:
586
587 www.example.com
588 443
589 0.0.0.0
590 0
591
592 15
593 3
594 30
595
596
598 This example shows a TCP-client configured to connect via a proxy:
600
601 www.example.com
602 443
603 0.0.0.0
604 0
605
606
607 proxy.my-domain.com
608 1080
609
610
611 foobar
612 secret
613
614
615
616
617
618 15
619 3
620 30
621
622
624 3.3. YANG Module
626 The ietf-tcp-client YANG module references [RFC6991].
628 file "ietf-tcp-client@2020-08-20.yang"
630 module ietf-tcp-client {
631 yang-version 1.1;
632 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
633 prefix tcpc;
635 import ietf-inet-types {
636 prefix inet;
637 reference
638 "RFC 6991: Common YANG Data Types";
639 }
641 import ietf-crypto-types {
642 prefix ct;
643 reference
644 "RFC AAAA: YANG Data Types and Groupings for Cryptography";
645 }
647 import ietf-tcp-common {
648 prefix tcpcmn;
649 reference
650 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
651 }
653 organization
654 "IETF NETCONF (Network Configuration) Working Group and the
655 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
657 contact
658 "WG Web:
659
660 WG List:
661
662 Authors: Kent Watsen
663 Michael Scharf
664 ";
666 description
667 "This module defines reusable groupings for TCP clients that
668 can be used as a basis for specific TCP client instances.
670 Copyright (c) 2020 IETF Trust and the persons identified
671 as authors of the code. All rights reserved.
673 Redistribution and use in source and binary forms, with
674 or without modification, is permitted pursuant to, and
675 subject to the license terms contained in, the Simplified
676 BSD License set forth in Section 4.c of the IETF Trust's
677 Legal Provisions Relating to IETF Documents
678 (https://trustee.ietf.org/license-info).
680 This version of this YANG module is part of RFC DDDD
681 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
682 itself for full legal notices.
684 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
685 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
686 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
687 are to be interpreted as described in BCP 14 (RFC 2119)
688 (RFC 8174) when, and only when, they appear in all
689 capitals, as shown here.";
691 revision 2020-08-20 {
692 description
693 "Initial version";
694 reference
695 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
697 }
699 // Features
701 feature local-binding-supported {
702 description
703 "Indicates that the server supports configuring local
704 bindings (i.e., the local address and local port) for
705 TCP clients.";
706 }
708 feature tcp-client-keepalives {
709 description
710 "Per socket TCP keepalive parameters are configurable for
711 TCP clients on the server implementing this feature.";
712 }
714 feature proxy-connect {
715 description
716 "Proxy connection configuration is configurable for
717 TCP clients on the server implementing this feature.";
718 }
720 feature socks5-gss-api {
721 description
722 "Indicates that the server supports authenticating
723 using GSSAPI when initiating TCP connections via
724 and SOCKS Version 5 proxy server.";
725 reference
726 "RFC 1928: SOCKS Protocol Version 5";
727 }
729 feature socks5-username-password {
730 description
731 "Indicates that the server supports authenticating
732 using username/password when initiating TCP
733 connections via and SOCKS Version 5 proxy
734 server.";
735 reference
736 "RFC 1928: SOCKS Protocol Version 5";
737 }
739 // Groupings
741 grouping tcp-client-grouping {
742 description
743 "A reusable grouping for configuring a TCP client.
745 Note that this grouping uses fairly typical descendent
746 node names such that a stack of 'uses' statements will
747 have name conflicts. It is intended that the consuming
748 data model will resolve the issue (e.g., by wrapping
749 the 'uses' statement in a container called
750 'tcp-client-parameters'). This model purposely does
751 not do this itself so as to provide maximum flexibility
752 to consuming models.";
754 leaf remote-address {
755 type inet:host;
756 mandatory true;
757 description
758 "The IP address or hostname of the remote peer to
759 establish a connection with. If a domain name is
760 configured, then the DNS resolution should happen on
761 each connection attempt. If the DNS resolution
762 results in multiple IP addresses, the IP addresses
763 are tried according to local preference order until
764 a connection has been established or until all IP
765 addresses have failed.";
766 }
767 leaf remote-port {
768 type inet:port-number;
769 default "0";
770 description
771 "The IP port number for the remote peer to establish a
772 connection with. An invalid default value (0) is used
773 (instead of 'mandatory true') so that as application
774 level data model may 'refine' it with an application
775 specific default port number value.";
776 }
777 leaf local-address {
778 if-feature "local-binding-supported";
779 type inet:ip-address;
780 description
781 "The local IP address/interface (VRF?) to bind to for when
782 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
783 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
784 explicitly indicate the implicit default, that the server
785 can bind to any IPv4 or IPv6 addresses, respectively.";
786 }
787 leaf local-port {
788 if-feature "local-binding-supported";
789 type inet:port-number;
790 default "0";
791 description
792 "The local IP port number to bind to for when connecting
793 to the remote peer. The port number '0', which is the
794 default value, indicates that any available local port
795 number may be used.";
796 }
798 container proxy-server {
799 if-feature "proxy-connect";
800 presence
801 "Indicates that a proxy connection is configured.
802 Present so that the 'proxy-type' node's 'mandatory
803 true' doesn't imply that the proxy connection
804 must be configured.";
805 choice proxy-type {
806 mandatory true;
807 description
808 "Selects a proxy connection protocol.";
809 case socks4 {
810 container socks4-parameters {
811 leaf remote-address {
812 type inet:ip-address;
813 mandatory true;
814 description
815 "The IP address of the proxy server.";
816 }
817 leaf remote-port {
818 type inet:port-number;
819 default "1080";
820 description
821 "The IP port number for the proxy server.";
822 }
823 description
824 "Parameters for connecting to a TCP-based proxy
825 server using the SOCKS4 protocol.";
826 reference
827 "SOCKS, Proceedings: 1992 Usenix Security Symposium.";
828 }
829 }
830 case socks4a {
831 container socks4a-parameters {
832 leaf remote-address {
833 type inet:host;
834 mandatory true;
835 description
836 "The IP address or hostname of the proxy server.";
837 }
838 leaf remote-port {
839 type inet:port-number;
840 default "1080";
841 description
842 "The IP port number for the proxy server.";
843 }
844 description
845 "Parameters for connecting to a TCP-based proxy
846 server using the SOCKS4a protocol.";
847 reference
848 "SOCKS Proceedings:
849 1992 Usenix Security Symposium.
850 OpenSSH message:
851 SOCKS 4A: A Simple Extension to SOCKS 4 Protocol
852 https://www.openssh.com/txt/socks4a.protocol";
853 }
854 }
855 case socks5 {
856 container socks5-parameters {
857 leaf remote-address {
858 type inet:host;
859 mandatory true;
860 description
861 "The IP address or hostname of the proxy server.";
862 }
863 leaf remote-port {
864 type inet:port-number;
865 default "1080";
866 description
867 "The IP port number for the proxy server.";
868 }
869 container authentication-parameters {
870 presence
871 "Indicates that an authentication mechanism
872 has been configured. Present so that the
873 'auth-type' node's 'mandatory true' doesn't
874 imply that an authentication mechanism
875 must be configured.";
876 description
877 "A container for SOCKS Version 5 authentication
878 mechanisms.
880 A complete list of methods is defined at:
881 https://www.iana.org/assignments/socks-methods
882 /socks-methods.xhtml.";
883 reference
884 "RFC 1928: SOCKS Protocol Version 5";
885 choice auth-type {
886 mandatory true;
887 description
888 "A choice amongst supported SOCKS Version 5
889 authentication mechanisms.";
890 case gss-api {
891 if-feature socks5-gss-api;
892 container gss-api {
893 description
894 "Contains GSS-API configuration. Defines
895 as an empty container to enable specific
896 GSS-API configuration to be augmented in
897 by future modules.";
898 reference
899 "RFC 1928: SOCKS Protocol Version 5
900 RFC 2743: Generic Security Service
901 Application Program Interface
902 Version 2, Update 1";
903 }
904 }
905 case username-password {
906 if-feature socks5-username-password;
907 container username-password {
908 leaf username {
909 type string;
910 mandatory true;
911 description
912 "The 'username' value to use for client
913 identification.";
914 }
915 uses ct:password-grouping {
916 description
917 "The password to be used for client
918 authentication.";
919 }
920 description
921 "Contains Username/Password configuration.";
922 reference
923 "RFC 1929: Username/Password Authentication
924 for SOCKS V5";
925 }
926 }
927 }
928 }
929 description
930 "Parameters for connecting to a TCP-based proxy server
931 using the SOCKS5 protocol.";
932 reference
933 "RFC 1928: SOCKS Protocol Version 5";
934 }
935 }
936 }
937 description
938 "Proxy server settings.";
939 }
941 uses tcpcmn:tcp-connection-grouping {
942 augment "keepalives" {
943 if-feature "tcp-client-keepalives";
944 description
945 "Add an if-feature statement so that implementations
946 can choose to support TCP client keepalives.";
947 }
948 }
949 }
950 }
952
954 4. The "ietf-tcp-server" Module
956 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp-
957 server". A high-level overview of the module is provided in
958 Section 4.1. Examples illustatrating the module's use are provided
959 in Examples (Section 4.2). The YANG module itself is defined in
960 Section 4.3.
962 4.1. Data Model Overview
964 This section provides an overview of the "ietf-tcp-server" module in
965 terms of its features and groupings.
967 4.1.1. Features
969 The following diagram lists all the "feature" statements defined in
970 the "ietf-tcp-server" module:
972 Features:
973 +-- tcp-server-keepalives
975 | The diagram above uses syntax that is similar to but not
976 | defined in [RFC8340].
978 4.1.2. Groupings
980 The following diagram lists all the "grouping" statements defined in
981 the "ietf-tcp-server" module:
983 Groupings:
984 +-- tcp-server-grouping
985 | The diagram above uses syntax that is similar to but not
986 | defined in [RFC8340].
988 Each of these groupings are presented in the following subsections.
990 4.1.2.1. The "tcp-server-grouping" Grouping
992 The following tree diagram [RFC8340] illustrates the "tcp-server-
993 grouping" grouping:
995 grouping tcp-server-grouping
996 +-- local-address inet:ip-address
997 +-- local-port? inet:port-number
998 +---u tcpcmn:tcp-connection-grouping
1000 Comments:
1002 * The "local-address" node, which is mandatory, may be configured as
1003 an IPv4 address, an IPv6 address, or a wildcard value.
1005 * The "local-port" node is not mandatory, but its default value is
1006 the invalid value '0', thus forcing the consuming data model to
1007 refine it in order to provide it an appropriate default value.
1009 * This grouping uses the "tcp-connection-grouping" grouping
1010 discussed in Section 2.1.3.2.
1012 4.1.3. Protocol-accessible Nodes
1014 The "ietf-tcp-server" module does not contain any protocol-accessible
1015 nodes.
1017 4.2. Example Usage
1019 This section presents an example showing the "tcp-server-grouping"
1020 populated with some data.
1022
1023 10.20.30.40
1024 7777
1025
1026 15
1027 3
1028 30
1029
1030
1032 4.3. YANG Module
1034 The ietf-tcp-server YANG module references [RFC6991].
1036 file "ietf-tcp-server@2020-08-20.yang"
1038 module ietf-tcp-server {
1039 yang-version 1.1;
1040 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
1041 prefix tcps;
1043 import ietf-inet-types {
1044 prefix inet;
1045 reference
1046 "RFC 6991: Common YANG Data Types";
1047 }
1049 import ietf-tcp-common {
1050 prefix tcpcmn;
1051 reference
1052 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
1053 }
1055 organization
1056 "IETF NETCONF (Network Configuration) Working Group and the
1057 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
1059 contact
1060 "WG Web:
1061
1062 WG List:
1063
1064 Authors: Kent Watsen
1065 Michael Scharf
1066 ";
1068 description
1069 "This module defines reusable groupings for TCP servers that
1070 can be used as a basis for specific TCP server instances.
1072 Copyright (c) 2020 IETF Trust and the persons identified
1073 as authors of the code. All rights reserved.
1075 Redistribution and use in source and binary forms, with
1076 or without modification, is permitted pursuant to, and
1077 subject to the license terms contained in, the Simplified
1078 BSD License set forth in Section 4.c of the IETF Trust's
1079 Legal Provisions Relating to IETF Documents
1080 (https://trustee.ietf.org/license-info).
1082 This version of this YANG module is part of RFC DDDD
1083 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
1084 itself for full legal notices.
1086 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1087 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1088 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1089 are to be interpreted as described in BCP 14 (RFC 2119)
1090 (RFC 8174) when, and only when, they appear in all
1091 capitals, as shown here.";
1093 revision 2020-08-20 {
1094 description
1095 "Initial version";
1096 reference
1097 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
1098 }
1100 // Features
1102 feature tcp-server-keepalives {
1103 description
1104 "Per socket TCP keepalive parameters are configurable for
1105 TCP servers on the server implementing this feature.";
1106 }
1108 // Groupings
1110 grouping tcp-server-grouping {
1111 description
1112 "A reusable grouping for configuring a TCP server.
1114 Note that this grouping uses fairly typical descendent
1115 node names such that a stack of 'uses' statements will
1116 have name conflicts. It is intended that the consuming
1117 data model will resolve the issue (e.g., by wrapping
1118 the 'uses' statement in a container called
1119 'tcp-server-parameters'). This model purposely does
1120 not do this itself so as to provide maximum flexibility
1121 to consuming models.";
1122 leaf local-address {
1123 type inet:ip-address;
1124 mandatory true;
1125 description
1126 "The local IP address to listen on for incoming
1127 TCP client connections. INADDR_ANY (0.0.0.0) or
1128 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
1129 used when the server is to listen on all IPv4 or
1130 IPv6 addresses, respectively.";
1131 }
1132 leaf local-port {
1133 type inet:port-number;
1134 default "0";
1135 description
1136 "The local port number to listen on for incoming TCP
1137 client connections. An invalid default value (0)
1138 is used (instead of 'mandatory true') so that an
1139 application level data model may 'refine' it with
1140 an application specific default port number value.";
1141 }
1142 uses tcpcmn:tcp-connection-grouping {
1143 augment "keepalives" {
1144 if-feature "tcp-server-keepalives";
1145 description
1146 "Add an if-feature statement so that implementations
1147 can choose to support TCP server keepalives.";
1148 }
1149 }
1150 }
1151 }
1153
1155 5. Security Considerations
1157 5.1. The "ietf-tcp-common" YANG Module
1159 The "ietf-tcp-common" YANG module defines "grouping" statements that
1160 are designed to be accessed via YANG based management protocols, such
1161 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1162 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1163 with mutual authentication.
1165 The NETCONF access control model (NACM) [RFC8341] provides the means
1166 to restrict access for particular users to a pre-configured subset of
1167 all available protocol operations and content.
1169 Since the module in this document only define groupings, these
1170 considerations are primarily for the designers of other modules that
1171 use these groupings.
1173 None of the readable data nodes defined in this YANG module are
1174 considered sensitive or vulnerable in network environments. The NACM
1175 "default-deny-all" extension has not been set for any data nodes
1176 defined in this module.
1178 None of the writable data nodes defined in this YANG module are
1179 considered sensitive or vulnerable in network environments. The NACM
1180 "default-deny-write" extension has not been set for any data nodes
1181 defined in this module.
1183 This module does not define any RPCs, actions, or notifications, and
1184 thus the security consideration for such is not provided here.
1186 5.2. The "ietf-tcp-client" YANG Module
1188 The "ietf-tcp-client" YANG module defines "grouping" statements that
1189 are designed to be accessed via YANG based management protocols, such
1190 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1191 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1192 with mutual authentication.
1194 The NETCONF access control model (NACM) [RFC8341] provides the means
1195 to restrict access for particular users to a pre-configured subset of
1196 all available protocol operations and content.
1198 Since the module in this document only define groupings, these
1199 considerations are primarily for the designers of other modules that
1200 use these groupings.
1202 One readable data node defined in this YANG module may be considered
1203 sensitive or vulnerable in some network environments. This node is
1204 as follows:
1206 * The "proxy-server/socks5-parameters/authentication-parameters/
1207 username-password/password" node:
1209 The cleartext "password" node defined in the "tcp-client-
1210 grouping" grouping is additionally sensitive to read operations
1211 such that, in normal use cases, it should never be returned to
1212 a client. For this reason, the NACM extension "default-deny-
1213 all" has been applied to it.
1215 None of the writable data nodes defined in this YANG module are
1216 considered sensitive or vulnerable in network environments. The NACM
1217 "default-deny-write" extension has not been set for any data nodes
1218 defined in this module.
1220 This module does not define any RPCs, actions, or notifications, and
1221 thus the security consideration for such is not provided here.
1223 5.3. The "ietf-tcp-server" YANG Module
1225 The "ietf-tcp-server" YANG module defines "grouping" statements that
1226 are designed to be accessed via YANG based management protocols, such
1227 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1228 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1229 with mutual authentication.
1231 The NETCONF access control model (NACM) [RFC8341] provides the means
1232 to restrict access for particular users to a pre-configured subset of
1233 all available protocol operations and content.
1235 Since the module in this document only define groupings, these
1236 considerations are primarily for the designers of other modules that
1237 use these groupings.
1239 None of the readable data nodes defined in this YANG module are
1240 considered sensitive or vulnerable in network environments. The NACM
1241 "default-deny-all" extension has not been set for any data nodes
1242 defined in this module.
1244 None of the writable data nodes defined in this YANG module are
1245 considered sensitive or vulnerable in network environments. The NACM
1246 "default-deny-write" extension has not been set for any data nodes
1247 defined in this module.
1249 This module does not define any RPCs, actions, or notifications, and
1250 thus the security consideration for such is not provided here.
1252 6. IANA Considerations
1254 6.1. The "IETF XML" Registry
1256 This document registers two URIs in the "ns" subregistry of the IETF
1257 XML Registry [RFC3688]. Following the format in [RFC3688], the
1258 following registrations are requested:
1260 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common
1261 Registrant Contact: The NETCONF WG of the IETF.
1262 XML: N/A, the requested URI is an XML namespace.
1264 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
1265 Registrant Contact: The NETCONF WG of the IETF.
1266 XML: N/A, the requested URI is an XML namespace.
1268 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
1269 Registrant Contact: The NETCONF WG of the IETF.
1270 XML: N/A, the requested URI is an XML namespace.
1272 6.2. The "YANG Module Names" Registry
1274 This document registers two YANG modules in the YANG Module Names
1275 registry [RFC6020]. Following the format in [RFC6020], the following
1276 registrations are requested:
1278 name: ietf-tcp-common
1279 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
1280 prefix: tcpcmn
1281 reference: RFC DDDD
1283 name: ietf-tcp-client
1284 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
1285 prefix: tcpc
1286 reference: RFC DDDD
1288 name: ietf-tcp-server
1289 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
1290 prefix: tcps
1291 reference: RFC DDDD
1293 7. References
1295 7.1. Normative References
1297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1298 Requirement Levels", BCP 14, RFC 2119,
1299 DOI 10.17487/RFC2119, March 1997,
1300 .
1302 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1303 the Network Configuration Protocol (NETCONF)", RFC 6020,
1304 DOI 10.17487/RFC6020, October 2010,
1305 .
1307 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1308 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1309 .
1311 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1312 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1313 .
1315 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1316 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1317 May 2017, .
1319 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1320 Access Control Model", STD 91, RFC 8341,
1321 DOI 10.17487/RFC8341, March 2018,
1322 .
1324 7.2. Informative References
1326 [I-D.ietf-netconf-crypto-types]
1327 Watsen, K., "YANG Data Types and Groupings for
1328 Cryptography", Work in Progress, Internet-Draft, draft-
1329 ietf-netconf-crypto-types-17, 10 July 2020,
1330 .
1333 [I-D.ietf-netconf-http-client-server]
1334 Watsen, K., "YANG Groupings for HTTP Clients and HTTP
1335 Servers", Work in Progress, Internet-Draft, draft-ietf-
1336 netconf-http-client-server-04, 8 July 2020,
1337 .
1340 [I-D.ietf-netconf-keystore]
1341 Watsen, K., "A YANG Data Model for a Keystore", Work in
1342 Progress, Internet-Draft, draft-ietf-netconf-keystore-19,
1343 10 July 2020, .
1346 [I-D.ietf-netconf-netconf-client-server]
1347 Watsen, K., "NETCONF Client and Server Models", Work in
1348 Progress, Internet-Draft, draft-ietf-netconf-netconf-
1349 client-server-20, 8 July 2020,
1350 .
1353 [I-D.ietf-netconf-restconf-client-server]
1354 Watsen, K., "RESTCONF Client and Server Models", Work in
1355 Progress, Internet-Draft, draft-ietf-netconf-restconf-
1356 client-server-20, 8 July 2020,
1357 .
1360 [I-D.ietf-netconf-ssh-client-server]
1361 Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and
1362 SSH Servers", Work in Progress, Internet-Draft, draft-
1363 ietf-netconf-ssh-client-server-21, 10 July 2020,
1364 .
1367 [I-D.ietf-netconf-tcp-client-server]
1368 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients
1369 and TCP Servers", Work in Progress, Internet-Draft, draft-
1370 ietf-netconf-tcp-client-server-07, 8 July 2020,
1371 .
1374 [I-D.ietf-netconf-tls-client-server]
1375 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and
1376 TLS Servers", Work in Progress, Internet-Draft, draft-
1377 ietf-netconf-tls-client-server-21, 10 July 2020,
1378 .
1381 [I-D.ietf-netconf-trust-anchors]
1382 Watsen, K., "A YANG Data Model for a Truststore", Work in
1383 Progress, Internet-Draft, draft-ietf-netconf-trust-
1384 anchors-12, 10 July 2020, .
1387 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1388 DOI 10.17487/RFC3688, January 2004,
1389 .
1391 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1392 and A. Bierman, Ed., "Network Configuration Protocol
1393 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1394 .
1396 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1397 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1398 .
1400 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1401 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1402 .
1404 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
1405 and R. Wilton, "Network Management Datastore Architecture
1406 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
1407 .
1409 Appendix A. Change Log
1411 This section is to be removed before publishing as an RFC.
1413 A.1. 00 to 01
1415 * Added 'local-binding-supported' feature to TCP-client model.
1417 * Added 'keepalives-supported' feature to TCP-common model.
1419 * Added 'external-endpoint-values' container and 'external-
1420 endpoints' feature to TCP-server model.
1422 A.2. 01 to 02
1424 * Removed the 'external-endpoint-values' container and 'external-
1425 endpoints' feature from the TCP-server model.
1427 A.3. 02 to 03
1429 * Moved the common model section to be before the client and server
1430 specific sections.
1432 * Added sections "Model Scope" and "Usage Guidelines for Configuring
1433 TCP Keep-Alives" to the common model section.
1435 A.4. 03 to 04
1437 * Fixed a few typos.
1439 A.5. 04 to 05
1441 * Removed commented out "grouping tcp-system-grouping" statement
1442 kept for reviewers.
1444 * Added a "Note to Reviewers" note to first page.
1446 A.6. 05 to 06
1447 * Added support for TCP proxies.
1449 A.7. 06 to 07
1451 * Expanded "Data Model Overview section(s) [remove "wall" of tree
1452 diagrams].
1454 * Updated the Security Considerations section.
1456 A.8. 08 to 09
1458 * Added missing IANA registration for "ietf-tcp-common"
1460 * Added "mandatory true" for the "username" and "password" leafs
1462 * Added an example of a TCP-client configured to connect via a proxy
1464 * Fixed issues found by the SecDir review of the "keystore" draft.
1466 * Updated the "ietf-tcp-client" module to use the new "password-
1467 grouping" grouping from the "crypto-types" module.
1469 Authors' Addresses
1471 Kent Watsen
1472 Watsen Networks
1474 Email: kent+ietf@watsen.net
1476 Michael Scharf
1477 Hochschule Esslingen - University of Applied Sciences
1479 Email: michael.scharf@hs-esslingen.de