idnits 2.17.1
draft-ietf-netconf-tcp-client-server-12.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 273 has weird spacing: '...nterval uin...'
== Line 533 has weird spacing: '...address ine...'
== Line 537 has weird spacing: '...address ine...'
-- The document date (7 March 2022) is 780 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)
== Outdated reference: A later version (-34) exists of
draft-ietf-netconf-crypto-types-21
== Outdated reference: A later version (-20) exists of
draft-ietf-netconf-http-client-server-08
== Outdated reference: A later version (-35) exists of
draft-ietf-netconf-keystore-23
== Outdated reference: A later version (-36) exists of
draft-ietf-netconf-netconf-client-server-24
== Outdated reference: A later version (-36) exists of
draft-ietf-netconf-restconf-client-server-24
== Outdated reference: A later version (-40) exists of
draft-ietf-netconf-ssh-client-server-26
== Outdated reference: A later version (-26) exists of
draft-ietf-netconf-tcp-client-server-11
== Outdated reference: A later version (-41) exists of
draft-ietf-netconf-tls-client-server-26
== Outdated reference: A later version (-28) exists of
draft-ietf-netconf-trust-anchors-16
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Watsen Networks
4 Intended status: Standards Track M. Scharf
5 Expires: 8 September 2022 Hochschule Esslingen
6 7 March 2022
8 YANG Groupings for TCP Clients and TCP Servers
9 draft-ietf-netconf-tcp-client-server-12
11 Abstract
13 This document defines three YANG 1.1 modules to support the
14 configuration of TCP clients and TCP servers. The modules include
15 basic parameters of a TCP connection relevant for client or server
16 applications, as well as client configuration required for traversing
17 proxies. The modules can be used either standalone or in conjunction
18 with configuration of other stack protocol layers.
20 Editorial Note (To be removed by RFC Editor)
22 This draft contains placeholder values that need to be replaced with
23 finalized values at the time of publication. This note summarizes
24 all of the substitutions that are needed. No other RFC Editor
25 instructions are specified elsewhere in this document.
27 Artwork in this document contains shorthand references to drafts in
28 progress. Please apply the following replacements:
30 * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-
31 types
33 * DDDD --> the assigned RFC value for this draft
35 Artwork in this document contains placeholder values for the date of
36 publication of this draft. Please apply the following replacement:
38 * 2022-03-07 --> the publication date of this draft
40 The following Appendix section is to be removed prior to publication:
42 * Appendix A. Change Log
44 Status of This Memo
46 This Internet-Draft is submitted in full conformance with the
47 provisions of BCP 78 and BCP 79.
49 Internet-Drafts are working documents of the Internet Engineering
50 Task Force (IETF). Note that other groups may also distribute
51 working documents as Internet-Drafts. The list of current Internet-
52 Drafts is at https://datatracker.ietf.org/drafts/current/.
54 Internet-Drafts are draft documents valid for a maximum of six months
55 and may be updated, replaced, or obsoleted by other documents at any
56 time. It is inappropriate to use Internet-Drafts as reference
57 material or to cite them other than as "work in progress."
59 This Internet-Draft will expire on 8 September 2022.
61 Copyright Notice
63 Copyright (c) 2022 IETF Trust and the persons identified as the
64 document authors. All rights reserved.
66 This document is subject to BCP 78 and the IETF Trust's Legal
67 Provisions Relating to IETF Documents (https://trustee.ietf.org/
68 license-info) in effect on the date of publication of this document.
69 Please review these documents carefully, as they describe your rights
70 and restrictions with respect to this document. Code Components
71 extracted from this document must include Revised BSD License text as
72 described in Section 4.e of the Trust Legal Provisions and are
73 provided without warranty as described in the Revised BSD License.
75 Table of Contents
77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
78 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3
79 1.2. Specification Language . . . . . . . . . . . . . . . . . 5
80 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5
81 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
82 2. The "ietf-tcp-common" Module . . . . . . . . . . . . . . . . 6
83 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6
84 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8
85 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
86 3. The "ietf-tcp-client" Module . . . . . . . . . . . . . . . . 11
87 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 11
88 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13
89 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14
90 4. The "ietf-tcp-server" Module . . . . . . . . . . . . . . . . 21
91 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 21
92 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 23
93 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23
94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
95 5.1. The "ietf-tcp-common" YANG Module . . . . . . . . . . . . 26
96 5.2. The "ietf-tcp-client" YANG Module . . . . . . . . . . . . 26
97 5.3. The "ietf-tcp-server" YANG Module . . . . . . . . . . . . 27
98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
99 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 28
100 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 28
101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
102 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
103 7.2. Informative References . . . . . . . . . . . . . . . . . 29
104 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31
105 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 31
106 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 32
107 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 32
108 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 32
109 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 32
110 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 32
111 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 32
112 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 32
113 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 33
114 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 33
115 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 33
116 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 33
117 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33
118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
120 1. Introduction
122 This document defines three YANG 1.1 [RFC7950] modules to support the
123 configuration of TCP clients and TCP servers (TCP is defined in
124 [RFC0793]), either as standalone or in conjunction with configuration
125 of other stack protocol layers.
127 The modules focus on three different types of base TCP parameters
128 that matter for TCP-based applications: First, the modules cover
129 fundamental configuration of a TCP client or TCP server application,
130 such as addresses and port numbers. Second, a reusable grouping
131 enables modification of application-specific parameters for a TCP
132 connections, such as use of TCP keep-alives. And third, client
133 configuration for traversing proxies is included as well. In each
134 case, the modules have a very narrow scope and focus on a minimum set
135 of required parameters.
137 1.1. Relation to other RFCs
139 This document presents one or more YANG modules [RFC7950] that are
140 part of a collection of RFCs that work together to, ultimately,
141 enable the configuration of the clients and servers of both the
142 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols.
144 The modules have been defined in a modular fashion to enable their
145 use by other efforts, some of which are known to be in progress at
146 the time of this writing, with many more expected to be defined in
147 time.
149 The normative dependency relationship between the various RFCs in the
150 collection is presented in the below diagram. The labels in the
151 diagram represent the primary purpose provided by each RFC.
152 Hyperlinks to each RFC are provided below the diagram.
154 crypto-types
155 ^ ^
156 / \
157 / \
158 truststore keystore
159 ^ ^ ^ ^
160 | +---------+ | |
161 | | | |
162 | +------------+ |
163 tcp-client-server | / | |
164 ^ ^ ssh-client-server | |
165 | | ^ tls-client-server
166 | | | ^ ^ http-client-server
167 | | | | | ^
168 | | | +-----+ +---------+ |
169 | | | | | |
170 | +-----------|--------|--------------+ | |
171 | | | | | |
172 +-----------+ | | | | |
173 | | | | | |
174 | | | | | |
175 netconf-client-server restconf-client-server
177 +=======================+===========================================+
178 |Label in Diagram | Originating RFC |
179 +=======================+===========================================+
180 |crypto-types | [I-D.ietf-netconf-crypto-types] |
181 +-----------------------+-------------------------------------------+
182 |truststore | [I-D.ietf-netconf-trust-anchors] |
183 +-----------------------+-------------------------------------------+
184 |keystore | [I-D.ietf-netconf-keystore] |
185 +-----------------------+-------------------------------------------+
186 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] |
187 +-----------------------+-------------------------------------------+
188 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] |
189 +-----------------------+-------------------------------------------+
190 |tls-client-server | [I-D.ietf-netconf-tls-client-server] |
191 +-----------------------+-------------------------------------------+
192 |http-client-server | [I-D.ietf-netconf-http-client-server] |
193 +-----------------------+-------------------------------------------+
194 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] |
195 +-----------------------+-------------------------------------------+
196 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] |
197 +-----------------------+-------------------------------------------+
199 Table 1: Label to RFC Mapping
201 1.2. Specification Language
203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
205 "OPTIONAL" in this document are to be interpreted as described in BCP
206 14 [RFC2119] [RFC8174] when, and only when, they appear in all
207 capitals, as shown here.
209 1.3. Adherence to the NMDA
211 This document is compliant with the Network Management Datastore
212 Architecture (NMDA) [RFC8342]. It does not define any protocol
213 accessible nodes that are "config false".
215 1.4. Conventions
217 Various examples used in this document use a placeholder value for
218 binary data that has been base64 encoded (e.g., "BASE64VALUE=").
219 This placeholder value is used as real base64 encoded structures are
220 often many lines long and hence distracting to the example being
221 presented.
223 2. The "ietf-tcp-common" Module
225 This section defines a YANG 1.1 module called "ietf-tcp-common". A
226 high-level overview of the module is provided in Section 2.1.
227 Examples illustrating the module's use are provided in Examples
228 (Section 2.2). The YANG module itself is defined in Section 2.3.
230 2.1. Data Model Overview
232 This section provides an overview of the "ietf-tcp-common" module in
233 terms of its features and groupings.
235 2.1.1. Model Scope
237 This document defines a common "grouping" statement for basic TCP
238 connection parameters that matter to applications. In some TCP
239 stacks, such parameters can also directly be set by an application
240 using system calls, such as the sockets API. The base YANG model in
241 this document focuses on modeling TCP keep-alives. This base model
242 can be extended as needed.
244 2.1.2. Features
246 The following diagram lists all the "feature" statements defined in
247 the "ietf-tcp-common" module:
249 Features:
250 +-- keepalives-supported
252 | The diagram above uses syntax that is similar to but not
253 | defined in [RFC8340].
255 2.1.3. Groupings
257 The "ietf-tcp-common" module defines the following "grouping"
258 statement:
260 * tcp-common-grouping
262 This grouping is presented in the following subsection.
264 2.1.3.1. The "tcp-common-grouping" Grouping
266 The following tree diagram [RFC8340] illustrates the "tcp-common-
267 grouping" grouping:
269 grouping tcp-common-grouping
270 +-- keepalives! {keepalives-supported}?
271 +-- idle-time uint16
272 +-- max-probes uint16
273 +-- probe-interval uint16
275 Comments:
277 * The "keepalives" node is a "presence" node so that the mandatory
278 descendant nodes do not imply that keepalives must be configured.
280 * The "idle-time", "max-probes", and "probe-interval" nodes have the
281 common meanings. Please see the YANG module in Section 2.3 for
282 details.
284 2.1.4. Protocol-accessible Nodes
286 The "ietf-tcp-common" module defines only "grouping" statements that
287 are used by other modules to instantiate protocol-accessible nodes.
289 2.1.5. Guidelines for Configuring TCP Keep-Alives
291 Network stacks may include "keep-alives" in their TCP
292 implementations, although this practice is not universally accepted.
293 If keep-alives are included, [RFC1122] mandates that the application
294 MUST be able to turn them on or off for each TCP connection, and that
295 they MUST default to off.
297 Keep-alive mechanisms exist in many protocols. Depending on the
298 protocol stack, TCP keep-alives may only be one out of several
299 alternatives. Which mechanism(s) to use depends on the use case and
300 application requirements. If keep-alives are needed by an
301 application, it is RECOMMENDED that the aliveness check happens only
302 at the protocol layers that are meaningful to the application.
304 A TCP keep-alive mechanism SHOULD only be invoked in server
305 applications that might otherwise hang indefinitely and consume
306 resources unnecessarily if a client crashes or aborts a connection
307 during a network failure [RFC1122]. TCP keep-alives may consume
308 significant resources both in the network and in endpoints (e.g.,
309 battery power). In addition, frequent keep-alives risk network
310 congestion. The higher the frequency of keep-alives, the higher the
311 overhead.
313 Given the cost of keep-alives, parameters have to be configured
314 carefully:
316 * The default idle interval (leaf "idle-time") MUST default to no
317 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value
318 MAY be configured, but keep-alive messages SHOULD NOT be
319 transmitted more frequently than once every 15 seconds. Longer
320 intervals SHOULD be used when possible.
322 * The maximum number of sequential keep-alive probes that can fail
323 (leaf "max-probes") trades off responsiveness and robustness
324 against packet loss. ACK segments that contain no data are not
325 reliably transmitted by TCP. Consequently, if a keep-alive
326 mechanism is implemented it MUST NOT interpret failure to respond
327 to any specific probe as a dead connection [RFC1122]. Typically,
328 a single-digit number should suffice.
330 * TCP implementations may include a parameter for the number of
331 seconds between TCP keep-alive probes (leaf "probe-interval"). In
332 order to avoid congestion, the time interval between probes MUST
333 NOT be smaller than one second. Significantly longer intervals
334 SHOULD be used. It is important to note that keep-alive probes
335 (or replies) can get dropped due to network congestion. Sending
336 further probe messages into a congested path after a short
337 interval, without backing off timers, could cause harm and result
338 in a congestion collapse. Therefore it is essential to pick a
339 large, conservative value for this interval.
341 2.2. Example Usage
343 This section presents an example showing the "tcp-common-grouping"
344 populated with some data.
346
347
349
350
351 15
352 3
353 30
354
355
357 2.3. YANG Module
359 The ietf-tcp-common YANG module references [RFC6991].
361 file "ietf-tcp-common@2022-03-07.yang"
362 module ietf-tcp-common {
363 yang-version 1.1;
364 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
365 prefix tcpcmn;
367 organization
368 "IETF NETCONF (Network Configuration) Working Group and the
369 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
371 contact
372 "WG Web: https://datatracker.ietf.org/wg/netconf
373 https://datatracker.ietf.org/wg/tcpm
374 WG List: NETCONF WG list
375 TCPM WG list
376 Authors: Kent Watsen
377 Michael Scharf
378 ";
380 description
381 "This module defines reusable groupings for TCP commons that
382 can be used as a basis for specific TCP common instances.
384 Copyright (c) 2021 IETF Trust and the persons identified
385 as authors of the code. All rights reserved.
387 Redistribution and use in source and binary forms, with
388 or without modification, is permitted pursuant to, and
389 subject to the license terms contained in, the Revised
390 BSD License set forth in Section 4.c of the IETF Trust's
391 Legal Provisions Relating to IETF Documents
392 (https://trustee.ietf.org/license-info).
394 This version of this YANG module is part of RFC DDDD
395 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
396 itself for full legal notices.
398 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
399 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
400 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
401 are to be interpreted as described in BCP 14 (RFC 2119)
402 (RFC 8174) when, and only when, they appear in all
403 capitals, as shown here.";
405 revision 2022-03-07 {
406 description
407 "Initial version";
408 reference
409 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
411 }
413 // Features
415 feature keepalives-supported {
416 description
417 "Indicates that keepalives are supported.";
418 }
420 // Groupings
422 grouping tcp-common-grouping {
423 description
424 "A reusable grouping for configuring TCP parameters common
425 to TCP connections as well as the operating system as a
426 whole.";
427 container keepalives {
428 if-feature "keepalives-supported";
429 presence
430 "Indicates that keepalives are enabled. This statement is
431 present so the mandatory descendant nodes do not imply that
432 this node must be configured.";
433 description
434 "Configures the keep-alive policy, to proactively test the
435 aliveness of the TCP peer. An unresponsive TCP peer is
436 dropped after approximately (idle-time + max-probes
437 * probe-interval) seconds.";
438 leaf idle-time {
439 type uint16 {
440 range "1..max";
441 }
442 units "seconds";
443 mandatory true;
444 description
445 "Sets the amount of time after which if no data has been
446 received from the TCP peer, a TCP-level probe message
447 will be sent to test the aliveness of the TCP peer.
448 Two hours (7200 seconds) is safe value, per RFC 1122.";
449 reference
450 "RFC 1122:
451 Requirements for Internet Hosts -- Communication Layers";
452 }
453 leaf max-probes {
454 type uint16 {
455 range "1..max";
456 }
457 mandatory true;
458 description
459 "Sets the maximum number of sequential keep-alive probes
460 that can fail to obtain a response from the TCP peer
461 before assuming the TCP peer is no longer alive.";
462 }
463 leaf probe-interval {
464 type uint16 {
465 range "1..max";
466 }
467 units "seconds";
468 mandatory true;
469 description
470 "Sets the time interval between failed probes. The interval
471 SHOULD be significantly longer than one second in order to
472 avoid harm on a congested link.";
473 }
474 } // container keepalives
475 } // grouping tcp-common-grouping
477 }
479
481 3. The "ietf-tcp-client" Module
483 This section defines a YANG 1.1 module called "ietf-tcp-client". A
484 high-level overview of the module is provided in Section 3.1.
485 Examples illustrating the module's use are provided in Examples
486 (Section 3.2). The YANG module itself is defined in Section 3.3.
488 3.1. Data Model Overview
490 This section provides an overview of the "ietf-tcp-client" module in
491 terms of its features and groupings.
493 3.1.1. Features
495 The following diagram lists all the "feature" statements defined in
496 the "ietf-tcp-client" module:
498 Features:
499 +-- local-binding-supported
500 +-- tcp-client-keepalives
501 +-- proxy-connect
502 +-- socks5-gss-api
503 +-- socks5-username-password
505 | The diagram above uses syntax that is similar to but not
506 | defined in [RFC8340].
508 3.1.2. Groupings
510 The "ietf-tcp-client" module defines the following "grouping"
511 statement:
513 * tcp-client-grouping
515 This grouping is presented in the following subsection.
517 3.1.2.1. The "tcp-client-grouping" Grouping
519 The following tree diagram [RFC8340] illustrates the "tcp-client-
520 grouping" grouping:
522 grouping tcp-client-grouping
523 +-- remote-address inet:host
524 +-- remote-port? inet:port-number
525 +-- local-address? inet:ip-address
526 | {local-binding-supported}?
527 +-- local-port? inet:port-number
528 | {local-binding-supported}?
529 +-- proxy-server! {proxy-connect}?
530 | +-- (proxy-type)
531 | +--:(socks4)
532 | | +-- socks4-parameters
533 | | +-- remote-address inet:ip-address
534 | | +-- remote-port? inet:port-number
535 | +--:(socks4a)
536 | | +-- socks4a-parameters
537 | | +-- remote-address inet:host
538 | | +-- remote-port? inet:port-number
539 | +--:(socks5)
540 | +-- socks5-parameters
541 | +-- remote-address inet:host
542 | +-- remote-port? inet:port-number
543 | +-- authentication-parameters!
544 | +-- (auth-type)
545 | +--:(gss-api) {socks5-gss-api}?
546 | | +-- gss-api
547 | +--:(username-password)
548 | {socks5-username-password}?
549 | +-- username-password
550 | +-- username string
551 | +---u ct:password-grouping
552 +---u tcpcmn:tcp-common-grouping
554 Comments:
556 * The "remote-address" node, which is mandatory, may be configured
557 as an IPv4 address, an IPv6 address, a hostname.
559 * The "remote-port" node is not mandatory, but its default value is
560 the invalid value '0', thus forcing the consuming data model to
561 refine it in order to provide it an appropriate default value.
563 * The "local-address" node, which is enabled by the "local-binding-
564 supported" feature (Section 2.1.2), may be configured as an IPv4
565 address, an IPv6 address, or a wildcard value.
567 * The "local-port" node, which is enabled by the "local-binding-
568 supported" feature (Section 2.1.2), is not mandatory. Its default
569 value is '0', indicating that the operating system can pick an
570 arbitrary port number.
572 * The "proxy-server" node is enabled by a "feature" statement and,
573 for servers that enable it, is a "presence" container so that the
574 descendant "mandatory true" choice node does not imply that the
575 proxy-server node must be configured.
577 * This grouping uses the "tcp-common-grouping" grouping discussed in
578 Section 2.1.3.1.
580 3.1.3. Protocol-accessible Nodes
582 The "ietf-tcp-client" module defines only "grouping" statements that
583 are used by other modules to instantiate protocol-accessible nodes.
585 3.2. Example Usage
587 This section presents two examples showing the "tcp-client-grouping"
588 populated with some data. This example shows a TCP-client configured
589 to not connect via a proxy:
591
592
594
595 www.example.com
596 443
597 0.0.0.0
598 0
599
600 15
601 3
602 30
603
604
606 This example shows a TCP-client configured to connect via a proxy:
608
609
611
612 www.example.com
613 443
614 0.0.0.0
615 0
616
617
618 proxy.my-domain.com
619 1080
620
621
622 foobar
623 secret
624
625
626
627
628
629 15
630 3
631 30
632
633
635 3.3. YANG Module
637 The ietf-tcp-client YANG module references [RFC6991].
639 file "ietf-tcp-client@2022-03-07.yang"
641 module ietf-tcp-client {
642 yang-version 1.1;
643 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
644 prefix tcpc;
646 import ietf-inet-types {
647 prefix inet;
648 reference
649 "RFC 6991: Common YANG Data Types";
650 }
652 import ietf-crypto-types {
653 prefix ct;
654 reference
655 "RFC AAAA: YANG Data Types and Groupings for Cryptography";
656 }
658 import ietf-tcp-common {
659 prefix tcpcmn;
660 reference
661 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
662 }
664 organization
665 "IETF NETCONF (Network Configuration) Working Group and the
666 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
668 contact
669 "WG Web: https://datatracker.ietf.org/wg/netconf
670 https://datatracker.ietf.org/wg/tcpm
671 WG List: NETCONF WG list
672 TCPM WG list
673 Authors: Kent Watsen
674 Michael Scharf
675 ";
677 description
678 "This module defines reusable groupings for TCP clients that
679 can be used as a basis for specific TCP client instances.
681 Copyright (c) 2021 IETF Trust and the persons identified
682 as authors of the code. All rights reserved.
684 Redistribution and use in source and binary forms, with
685 or without modification, is permitted pursuant to, and
686 subject to the license terms contained in, the Revised
687 BSD License set forth in Section 4.c of the IETF Trust's
688 Legal Provisions Relating to IETF Documents
689 (https://trustee.ietf.org/license-info).
691 This version of this YANG module is part of RFC DDDD
692 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
693 itself for full legal notices.
695 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
696 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
697 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
698 are to be interpreted as described in BCP 14 (RFC 2119)
699 (RFC 8174) when, and only when, they appear in all
700 capitals, as shown here.";
702 revision 2022-03-07 {
703 description
704 "Initial version";
705 reference
706 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
707 }
709 // Features
711 feature local-binding-supported {
712 description
713 "Indicates that the server supports configuring local
714 bindings (i.e., the local address and local port) for
715 TCP clients.";
716 }
718 feature tcp-client-keepalives {
719 description
720 "Per socket TCP keepalive parameters are configurable for
721 TCP clients on the server implementing this feature.";
722 }
724 feature proxy-connect {
725 description
726 "Proxy connection configuration is configurable for
727 TCP clients on the server implementing this feature.";
728 }
730 feature socks5-gss-api {
731 description
732 "Indicates that the server supports authenticating
733 using GSSAPI when initiating TCP connections via
734 and SOCKS Version 5 proxy server.";
736 reference
737 "RFC 1928: SOCKS Protocol Version 5";
738 }
740 feature socks5-username-password {
741 description
742 "Indicates that the server supports authenticating using
743 username/password when initiating TCP connections via
744 and SOCKS Version 5 proxy server.";
745 reference
746 "RFC 1928: SOCKS Protocol Version 5";
747 }
749 // Groupings
751 grouping tcp-client-grouping {
752 description
753 "A reusable grouping for configuring a TCP client.
755 Note that this grouping uses fairly typical descendant
756 node names such that a stack of 'uses' statements will
757 have name conflicts. It is intended that the consuming
758 data model will resolve the issue (e.g., by wrapping
759 the 'uses' statement in a container called
760 'tcp-client-parameters'). This model purposely does
761 not do this itself so as to provide maximum flexibility
762 to consuming models.";
764 leaf remote-address {
765 type inet:host;
766 mandatory true;
767 description
768 "The IP address or hostname of the remote peer to
769 establish a connection with. If a domain name is
770 configured, then the DNS resolution should happen on
771 each connection attempt. If the DNS resolution
772 results in multiple IP addresses, the IP addresses
773 are tried according to local preference order until
774 a connection has been established or until all IP
775 addresses have failed.";
776 }
777 leaf remote-port {
778 type inet:port-number;
779 default "0";
780 description
781 "The IP port number for the remote peer to establish a
782 connection with. An invalid default value (0) is used
783 (instead of 'mandatory true') so that as application
784 level data model may 'refine' it with an application
785 specific default port number value.";
786 }
787 leaf local-address {
788 if-feature "local-binding-supported";
789 type inet:ip-address;
790 description
791 "The local IP address/interface (VRF?) to bind to for when
792 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
793 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
794 explicitly indicate the implicit default, that the server
795 can bind to any IPv4 or IPv6 addresses, respectively.";
796 }
797 leaf local-port {
798 if-feature "local-binding-supported";
799 type inet:port-number;
800 default "0";
801 description
802 "The local IP port number to bind to for when connecting
803 to the remote peer. The port number '0', which is the
804 default value, indicates that any available local port
805 number may be used.";
806 }
807 container proxy-server {
808 if-feature "proxy-connect";
809 presence
810 "Indicates that a proxy connection has been configured.
811 Present so that the mandatory descendant nodes do not
812 imply that this node must be configured.";
813 choice proxy-type {
814 mandatory true;
815 description
816 "Selects a proxy connection protocol.";
817 case socks4 {
818 container socks4-parameters {
819 leaf remote-address {
820 type inet:ip-address;
821 mandatory true;
822 description
823 "The IP address of the proxy server.";
824 }
825 leaf remote-port {
826 type inet:port-number;
827 default "1080";
828 description
829 "The IP port number for the proxy server.";
830 }
831 description
832 "Parameters for connecting to a TCP-based proxy
833 server using the SOCKS4 protocol.";
834 reference
835 "SOCKS, Proceedings: 1992 Usenix Security Symposium.";
836 }
837 }
838 case socks4a {
839 container socks4a-parameters {
840 leaf remote-address {
841 type inet:host;
842 mandatory true;
843 description
844 "The IP address or hostname of the proxy server.";
845 }
846 leaf remote-port {
847 type inet:port-number;
848 default "1080";
849 description
850 "The IP port number for the proxy server.";
851 }
852 description
853 "Parameters for connecting to a TCP-based proxy
854 server using the SOCKS4a protocol.";
855 reference
856 "SOCKS Proceedings:
857 1992 Usenix Security Symposium.
858 OpenSSH message:
859 SOCKS 4A: A Simple Extension to SOCKS 4 Protocol
860 https://www.openssh.com/txt/socks4a.protocol";
861 }
862 }
863 case socks5 {
864 container socks5-parameters {
865 leaf remote-address {
866 type inet:host;
867 mandatory true;
868 description
869 "The IP address or hostname of the proxy server.";
870 }
871 leaf remote-port {
872 type inet:port-number;
873 default "1080";
874 description
875 "The IP port number for the proxy server.";
876 }
877 container authentication-parameters {
878 presence
879 "Indicates that an authentication mechanism
880 has been configured. Present so that the
881 mandatory descendant nodes do not imply that
882 this node must be configured.";
883 description
884 "A container for SOCKS Version 5 authentication
885 mechanisms.
887 A complete list of methods is defined at:
888 https://www.iana.org/assignments/socks-methods
889 /socks-methods.xhtml.";
890 reference
891 "RFC 1928: SOCKS Protocol Version 5";
892 choice auth-type {
893 mandatory true;
894 description
895 "A choice amongst supported SOCKS Version 5
896 authentication mechanisms.";
897 case gss-api {
898 if-feature "socks5-gss-api";
899 container gss-api {
900 description
901 "Contains GSS-API configuration. Defines
902 as an empty container to enable specific
903 GSS-API configuration to be augmented in
904 by future modules.";
905 reference
906 "RFC 1928: SOCKS Protocol Version 5
907 RFC 2743: Generic Security Service
908 Application Program Interface
909 Version 2, Update 1";
910 }
911 }
912 case username-password {
913 if-feature "socks5-username-password";
914 container username-password {
915 leaf username {
916 type string;
917 mandatory true;
918 description
919 "The 'username' value to use for client
920 identification.";
921 }
922 uses ct:password-grouping {
923 description
924 "The password to be used for client
925 authentication.";
926 }
927 description
928 "Contains Username/Password configuration.";
929 reference
930 "RFC 1929: Username/Password Authentication
931 for SOCKS V5";
932 }
933 }
934 }
935 }
936 description
937 "Parameters for connecting to a TCP-based proxy server
938 using the SOCKS5 protocol.";
939 reference
940 "RFC 1928: SOCKS Protocol Version 5";
941 }
942 }
943 }
944 description
945 "Proxy server settings.";
946 }
948 uses tcpcmn:tcp-common-grouping {
949 augment "keepalives" {
950 if-feature "tcp-client-keepalives";
951 description
952 "Add an if-feature statement so that implementations
953 can choose to support TCP client keepalives.";
954 }
955 }
956 }
957 }
959
961 4. The "ietf-tcp-server" Module
963 This section defines a YANG 1.1 module called "ietf-tcp-server". A
964 high-level overview of the module is provided in Section 4.1.
965 Examples illustrating the module's use are provided in Examples
966 (Section 4.2). The YANG module itself is defined in Section 4.3.
968 4.1. Data Model Overview
970 This section provides an overview of the "ietf-tcp-server" module in
971 terms of its features and groupings.
973 4.1.1. Features
975 The following diagram lists all the "feature" statements defined in
976 the "ietf-tcp-server" module:
978 Features:
979 +-- tcp-server-keepalives
981 | The diagram above uses syntax that is similar to but not
982 | defined in [RFC8340].
984 4.1.2. Groupings
986 The "ietf-tcp-server" module defines the following "grouping"
987 statement:
989 * tcp-server-grouping
991 This grouping is presented in the following subsection.
993 4.1.2.1. The "tcp-server-grouping" Grouping
995 The following tree diagram [RFC8340] illustrates the "tcp-server-
996 grouping" grouping:
998 grouping tcp-server-grouping
999 +-- local-address inet:ip-address
1000 +-- local-port? inet:port-number
1001 +---u tcpcmn:tcp-common-grouping
1003 Comments:
1005 * The "local-address" node, which is mandatory, may be configured as
1006 an IPv4 address, an IPv6 address, or a wildcard value.
1008 * The "local-port" node is not mandatory, but its default value is
1009 the invalid value '0', thus forcing the consuming data model to
1010 refine it in order to provide it an appropriate default value.
1012 * This grouping uses the "tcp-common-grouping" grouping discussed in
1013 Section 2.1.3.1.
1015 4.1.3. Protocol-accessible Nodes
1017 The "ietf-tcp-server" module defines only "grouping" statements that
1018 are used by other modules to instantiate protocol-accessible nodes.
1020 4.2. Example Usage
1022 This section presents an example showing the "tcp-server-grouping"
1023 populated with some data.
1025
1026
1028
1029 10.20.30.40
1030 7777
1031
1032 15
1033 3
1034 30
1035
1036
1038 4.3. YANG Module
1040 The ietf-tcp-server YANG module references [RFC6991].
1042 file "ietf-tcp-server@2022-03-07.yang"
1044 module ietf-tcp-server {
1045 yang-version 1.1;
1046 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
1047 prefix tcps;
1049 import ietf-inet-types {
1050 prefix inet;
1051 reference
1052 "RFC 6991: Common YANG Data Types";
1053 }
1055 import ietf-tcp-common {
1056 prefix tcpcmn;
1057 reference
1058 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
1059 }
1061 organization
1062 "IETF NETCONF (Network Configuration) Working Group and the
1063 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
1065 contact
1066 "WG Web: https://datatracker.ietf.org/wg/netconf
1067 https://datatracker.ietf.org/wg/tcpm
1069 WG List: NETCONF WG list
1070 TCPM WG list
1071 Authors: Kent Watsen
1072 Michael Scharf
1073 ";
1075 description
1076 "This module defines reusable groupings for TCP servers that
1077 can be used as a basis for specific TCP server instances.
1079 Copyright (c) 2021 IETF Trust and the persons identified
1080 as authors of the code. All rights reserved.
1082 Redistribution and use in source and binary forms, with
1083 or without modification, is permitted pursuant to, and
1084 subject to the license terms contained in, the Revised
1085 BSD License set forth in Section 4.c of the IETF Trust's
1086 Legal Provisions Relating to IETF Documents
1087 (https://trustee.ietf.org/license-info).
1089 This version of this YANG module is part of RFC DDDD
1090 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
1091 itself for full legal notices.
1093 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1094 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1095 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1096 are to be interpreted as described in BCP 14 (RFC 2119)
1097 (RFC 8174) when, and only when, they appear in all
1098 capitals, as shown here.";
1100 revision 2022-03-07 {
1101 description
1102 "Initial version";
1103 reference
1104 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
1105 }
1107 // Features
1109 feature tcp-server-keepalives {
1110 description
1111 "Per socket TCP keepalive parameters are configurable for
1112 TCP servers on the server implementing this feature.";
1113 }
1115 // Groupings
1116 grouping tcp-server-grouping {
1117 description
1118 "A reusable grouping for configuring a TCP server.
1120 Note that this grouping uses fairly typical descendant
1121 node names such that a stack of 'uses' statements will
1122 have name conflicts. It is intended that the consuming
1123 data model will resolve the issue (e.g., by wrapping
1124 the 'uses' statement in a container called
1125 'tcp-server-parameters'). This model purposely does
1126 not do this itself so as to provide maximum flexibility
1127 to consuming models.";
1128 leaf local-address {
1129 type inet:ip-address;
1130 mandatory true;
1131 description
1132 "The local IP address to listen on for incoming
1133 TCP client connections. INADDR_ANY (0.0.0.0) or
1134 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
1135 used when the server is to listen on all IPv4 or
1136 IPv6 addresses, respectively.";
1137 }
1138 leaf local-port {
1139 type inet:port-number;
1140 default "0";
1141 description
1142 "The local port number to listen on for incoming TCP
1143 client connections. An invalid default value (0)
1144 is used (instead of 'mandatory true') so that an
1145 application level data model may 'refine' it with
1146 an application specific default port number value.";
1147 }
1148 uses tcpcmn:tcp-common-grouping {
1149 augment "keepalives" {
1150 if-feature "tcp-server-keepalives";
1151 description
1152 "Add an if-feature statement so that implementations
1153 can choose to support TCP server keepalives.";
1154 }
1155 }
1156 }
1157 }
1159
1161 5. Security Considerations
1163 5.1. The "ietf-tcp-common" YANG Module
1165 The "ietf-tcp-common" YANG module defines "grouping" statements that
1166 are designed to be accessed via YANG based management protocols, such
1167 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1168 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1169 with mutual authentication.
1171 The NETCONF access control model (NACM) [RFC8341] provides the means
1172 to restrict access for particular users to a pre-configured subset of
1173 all available protocol operations and content.
1175 Since the module in this document only define groupings, these
1176 considerations are primarily for the designers of other modules that
1177 use these groupings.
1179 None of the readable data nodes defined in this YANG module are
1180 considered sensitive or vulnerable in network environments. The NACM
1181 "default-deny-all" extension has not been set for any data nodes
1182 defined in this module.
1184 None of the writable data nodes defined in this YANG module are
1185 considered sensitive or vulnerable in network environments. The NACM
1186 "default-deny-write" extension has not been set for any data nodes
1187 defined in this module.
1189 This module does not define any RPCs, actions, or notifications, and
1190 thus the security consideration for such is not provided here.
1192 5.2. The "ietf-tcp-client" YANG Module
1194 The "ietf-tcp-client" YANG module defines "grouping" statements that
1195 are designed to be accessed via YANG based management protocols, such
1196 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1197 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1198 with mutual authentication.
1200 The NETCONF access control model (NACM) [RFC8341] provides the means
1201 to restrict access for particular users to a pre-configured subset of
1202 all available protocol operations and content.
1204 Since the module in this document only define groupings, these
1205 considerations are primarily for the designers of other modules that
1206 use these groupings.
1208 One readable data node defined in this YANG module may be considered
1209 sensitive or vulnerable in some network environments. This node is
1210 as follows:
1212 * The "proxy-server/socks5-parameters/authentication-parameters/
1213 username-password/password" node:
1215 The cleartext "password" node defined in the "tcp-client-
1216 grouping" grouping is additionally sensitive to read operations
1217 such that, in normal use cases, it should never be returned to
1218 a client. For this reason, the NACM extension "default-deny-
1219 all" has been applied to it.
1221 None of the writable data nodes defined in this YANG module are
1222 considered sensitive or vulnerable in network environments. The NACM
1223 "default-deny-write" extension has not been set for any data nodes
1224 defined in this module.
1226 This module does not define any RPCs, actions, or notifications, and
1227 thus the security consideration for such is not provided here.
1229 Implementations are RECOMMENDED to implement the "local-binding-
1230 supported" feature for cryptographically-secure protocols, so as to
1231 enable more granular ingress/egress firewall rulebases. It is NOT
1232 RECOMMENDED to implement this feature for unsecure protocols, as per
1233 [RFC6056].
1235 5.3. The "ietf-tcp-server" YANG Module
1237 The "ietf-tcp-server" YANG module defines "grouping" statements that
1238 are designed to be accessed via YANG based management protocols, such
1239 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1240 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1241 with mutual authentication.
1243 The NETCONF access control model (NACM) [RFC8341] provides the means
1244 to restrict access for particular users to a pre-configured subset of
1245 all available protocol operations and content.
1247 Since the module in this document only define groupings, these
1248 considerations are primarily for the designers of other modules that
1249 use these groupings.
1251 None of the readable data nodes defined in this YANG module are
1252 considered sensitive or vulnerable in network environments. The NACM
1253 "default-deny-all" extension has not been set for any data nodes
1254 defined in this module.
1256 None of the writable data nodes defined in this YANG module are
1257 considered sensitive or vulnerable in network environments. The NACM
1258 "default-deny-write" extension has not been set for any data nodes
1259 defined in this module.
1261 This module does not define any RPCs, actions, or notifications, and
1262 thus the security consideration for such is not provided here.
1264 6. IANA Considerations
1266 6.1. The "IETF XML" Registry
1268 This document registers two URIs in the "ns" subregistry of the IETF
1269 XML Registry [RFC3688]. Following the format in [RFC3688], the
1270 following registrations are requested:
1272 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common
1273 Registrant Contact: The IESG
1274 XML: N/A, the requested URI is an XML namespace.
1276 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
1277 Registrant Contact: The IESG
1278 XML: N/A, the requested URI is an XML namespace.
1280 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
1281 Registrant Contact: The IESG
1282 XML: N/A, the requested URI is an XML namespace.
1284 6.2. The "YANG Module Names" Registry
1286 This document registers two YANG modules in the YANG Module Names
1287 registry [RFC6020]. Following the format in [RFC6020], the following
1288 registrations are requested:
1290 name: ietf-tcp-common
1291 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
1292 prefix: tcpcmn
1293 reference: RFC DDDD
1295 name: ietf-tcp-client
1296 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
1297 prefix: tcpc
1298 reference: RFC DDDD
1300 name: ietf-tcp-server
1301 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
1302 prefix: tcps
1303 reference: RFC DDDD
1305 7. References
1307 7.1. Normative References
1309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1310 Requirement Levels", BCP 14, RFC 2119,
1311 DOI 10.17487/RFC2119, March 1997,
1312 .
1314 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1315 the Network Configuration Protocol (NETCONF)", RFC 6020,
1316 DOI 10.17487/RFC6020, October 2010,
1317 .
1319 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1320 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1321 .
1323 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1324 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1325 .
1327 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1328 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1329 May 2017, .
1331 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1332 Access Control Model", STD 91, RFC 8341,
1333 DOI 10.17487/RFC8341, March 2018,
1334 .
1336 7.2. Informative References
1338 [I-D.ietf-netconf-crypto-types]
1339 Watsen, K., "YANG Data Types and Groupings for
1340 Cryptography", Work in Progress, Internet-Draft, draft-
1341 ietf-netconf-crypto-types-21, 14 September 2021,
1342 .
1345 [I-D.ietf-netconf-http-client-server]
1346 Watsen, K., "YANG Groupings for HTTP Clients and HTTP
1347 Servers", Work in Progress, Internet-Draft, draft-ietf-
1348 netconf-http-client-server-08, 14 December 2021,
1349 .
1352 [I-D.ietf-netconf-keystore]
1353 Watsen, K., "A YANG Data Model for a Keystore", Work in
1354 Progress, Internet-Draft, draft-ietf-netconf-keystore-23,
1355 14 December 2021, .
1358 [I-D.ietf-netconf-netconf-client-server]
1359 Watsen, K., "NETCONF Client and Server Models", Work in
1360 Progress, Internet-Draft, draft-ietf-netconf-netconf-
1361 client-server-24, 14 December 2021,
1362 .
1365 [I-D.ietf-netconf-restconf-client-server]
1366 Watsen, K., "RESTCONF Client and Server Models", Work in
1367 Progress, Internet-Draft, draft-ietf-netconf-restconf-
1368 client-server-24, 14 December 2021,
1369 .
1372 [I-D.ietf-netconf-ssh-client-server]
1373 Watsen, K., "YANG Groupings for SSH Clients and SSH
1374 Servers", Work in Progress, Internet-Draft, draft-ietf-
1375 netconf-ssh-client-server-26, 14 December 2021,
1376 .
1379 [I-D.ietf-netconf-tcp-client-server]
1380 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients
1381 and TCP Servers", Work in Progress, Internet-Draft, draft-
1382 ietf-netconf-tcp-client-server-11, 14 December 2021,
1383 .
1386 [I-D.ietf-netconf-tls-client-server]
1387 Watsen, K., "YANG Groupings for TLS Clients and TLS
1388 Servers", Work in Progress, Internet-Draft, draft-ietf-
1389 netconf-tls-client-server-26, 14 December 2021,
1390 .
1393 [I-D.ietf-netconf-trust-anchors]
1394 Watsen, K., "A YANG Data Model for a Truststore", Work in
1395 Progress, Internet-Draft, draft-ietf-netconf-trust-
1396 anchors-16, 14 December 2021,
1397 .
1400 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1401 RFC 793, DOI 10.17487/RFC0793, September 1981,
1402 .
1404 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
1405 Communication Layers", STD 3, RFC 1122,
1406 DOI 10.17487/RFC1122, October 1989,
1407 .
1409 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1410 DOI 10.17487/RFC3688, January 2004,
1411 .
1413 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
1414 Protocol Port Randomization", BCP 156, RFC 6056,
1415 DOI 10.17487/RFC6056, January 2011,
1416 .
1418 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1419 and A. Bierman, Ed., "Network Configuration Protocol
1420 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1421 .
1423 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1424 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1425 .
1427 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1428 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1429 .
1431 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
1432 and R. Wilton, "Network Management Datastore Architecture
1433 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
1434 .
1436 Appendix A. Change Log
1438 This section is to be removed before publishing as an RFC.
1440 A.1. 00 to 01
1442 * Added 'local-binding-supported' feature to TCP-client model.
1444 * Added 'keepalives-supported' feature to TCP-common model.
1446 * Added 'external-endpoint-values' container and 'external-
1447 endpoints' feature to TCP-server model.
1449 A.2. 01 to 02
1451 * Removed the 'external-endpoint-values' container and 'external-
1452 endpoints' feature from the TCP-server model.
1454 A.3. 02 to 03
1456 * Moved the common model section to be before the client and server
1457 specific sections.
1459 * Added sections "Model Scope" and "Usage Guidelines for Configuring
1460 TCP Keep-Alives" to the common model section.
1462 A.4. 03 to 04
1464 * Fixed a few typos.
1466 A.5. 04 to 05
1468 * Removed commented out "grouping tcp-system-grouping" statement
1469 kept for reviewers.
1471 * Added a "Note to Reviewers" note to first page.
1473 A.6. 05 to 06
1475 * Added support for TCP proxies.
1477 A.7. 06 to 07
1479 * Expanded "Data Model Overview section(s) [remove "wall" of tree
1480 diagrams].
1482 * Updated the Security Considerations section.
1484 A.8. 07 to 08
1486 * Added missing IANA registration for "ietf-tcp-common"
1488 * Added "mandatory true" for the "username" and "password" leafs
1490 * Added an example of a TCP-client configured to connect via a proxy
1492 * Fixed issues found by the SecDir review of the "keystore" draft.
1494 * Updated the "ietf-tcp-client" module to use the new "password-
1495 grouping" grouping from the "crypto-types" module.
1497 A.9. 08 to 09
1499 * Addressed comments raised by YANG Doctor in the ct/ts/ks drafts.
1501 A.10. 09 to 10
1503 * Updated Abstract and Intro to address comments by Tom Petch.
1505 * Removed the "tcp-connection-grouping" grouping (now models use the
1506 "tcp-common-grouping" directly).
1508 * Added XML-comment above examples explaining the reason for the
1509 unusual top-most element's presence.
1511 * Added Securty Considerations section for the "local-binding-
1512 supported" feature.
1514 * Replaced some hardcoded refs to elements.
1516 * Fixed nits found by YANG Doctor reviews.
1518 * Aligned modules with `pyang -f` formatting.
1520 * Added an "Acknowledgements" secetion.
1522 A.11. 10 to 11
1524 * Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.
1526 * Minor editorial nits
1528 A.12. 11 to 12
1530 * Fixed up the 'WG Web' and 'WG List' lines in YANG module(s)
1532 * Fixed up copyright (i.e., s/Simplified/Revised/) in YANG module(s)
1534 Acknowledgements
1536 The authors would like to thank for following for lively discussions
1537 on list and in the halls (ordered by first name): Juergen
1538 Schoenwaelder, Ladislav Lhotka, Nick Hancock, and Tom Petch.
1540 Authors' Addresses
1542 Kent Watsen
1543 Watsen Networks
1544 Email: kent+ietf@watsen.net
1545 Michael Scharf
1546 Hochschule Esslingen - University of Applied Sciences
1547 Email: michael.scharf@hs-esslingen.de