idnits 2.17.1
draft-ietf-netconf-tcp-client-server-09.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 245 has weird spacing: '...nterval uin...'
== Line 414 has weird spacing: '...is node must ...'
== Line 523 has weird spacing: '...address ine...'
== Line 527 has weird spacing: '...address ine...'
-- The document date (10 February 2021) is 1142 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 313, but not defined
== Missing Reference: 'RFC793bis' is mentioned on line 279, 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-18
== Outdated reference: A later version (-20) exists of
draft-ietf-netconf-http-client-server-05
== Outdated reference: A later version (-35) exists of
draft-ietf-netconf-keystore-20
== Outdated reference: A later version (-36) exists of
draft-ietf-netconf-netconf-client-server-21
== Outdated reference: A later version (-36) exists of
draft-ietf-netconf-restconf-client-server-21
== Outdated reference: A later version (-40) exists of
draft-ietf-netconf-ssh-client-server-22
== Outdated reference: A later version (-24) exists of
draft-ietf-netconf-tcp-client-server-08
== Outdated reference: A later version (-41) exists of
draft-ietf-netconf-tls-client-server-22
== Outdated reference: A later version (-28) exists of
draft-ietf-netconf-trust-anchors-13
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: 14 August 2021 Hochschule Esslingen
6 10 February 2021
8 YANG Groupings for TCP Clients and TCP Servers
9 draft-ietf-netconf-tcp-client-server-09
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 * "2021-02-10" --> 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 14 August 2021.
55 Copyright Notice
57 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . 30
98 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . . . . . 31
105 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 31
106 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 32
107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
109 1. Introduction
111 This document defines three YANG 1.1 [RFC7950] modules to support the
112 configuration of TCP clients and TCP servers, either as standalone or
113 in conjunction with a stack protocol layer specific configurations.
115 1.1. Relation to other RFCs
117 This document presents one or more YANG modules [RFC7950] that are
118 part of a collection of RFCs that work together to, ultimately,
119 enable the configuration of the clients and servers of both the
120 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols.
122 The modules have been defined in a modular fashion to enable their
123 use by other efforts, some of which are known to be in progress at
124 the time of this writing, with many more expected to be defined in
125 time.
127 The normative dependency relationship between the various RFCs in the
128 collection is presented in the below diagram. The labels in the
129 diagram represent the primary purpose provided by each RFC.
130 Hyperlinks to each RFC are provided below the diagram.
132 crypto-types
133 ^ ^
134 / \
135 / \
136 truststore keystore
137 ^ ^ ^ ^
138 | +---------+ | |
139 | | | |
140 | +------------+ |
141 tcp-client-server | / | |
142 ^ ^ ssh-client-server | |
143 | | ^ tls-client-server
144 | | | ^ ^ http-client-server
145 | | | | | ^
146 | | | +-----+ +---------+ |
147 | | | | | |
148 | +-----------|--------|--------------+ | |
149 | | | | | |
150 +-----------+ | | | | |
151 | | | | | |
152 | | | | | |
153 netconf-client-server restconf-client-server
155 +=======================+===========================================+
156 |Label in Diagram | Originating RFC |
157 +=======================+===========================================+
158 |crypto-types | [I-D.ietf-netconf-crypto-types] |
159 +-----------------------+-------------------------------------------+
160 |truststore | [I-D.ietf-netconf-trust-anchors] |
161 +-----------------------+-------------------------------------------+
162 |keystore | [I-D.ietf-netconf-keystore] |
163 +-----------------------+-------------------------------------------+
164 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] |
165 +-----------------------+-------------------------------------------+
166 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] |
167 +-----------------------+-------------------------------------------+
168 |tls-client-server | [I-D.ietf-netconf-tls-client-server] |
169 +-----------------------+-------------------------------------------+
170 |http-client-server | [I-D.ietf-netconf-http-client-server] |
171 +-----------------------+-------------------------------------------+
172 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] |
173 +-----------------------+-------------------------------------------+
174 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] |
175 +-----------------------+-------------------------------------------+
177 Table 1: Label to RFC Mapping
179 1.2. Specification Language
181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
183 "OPTIONAL" in this document are to be interpreted as described in BCP
184 14 [RFC2119] [RFC8174] when, and only when, they appear in all
185 capitals, as shown here.
187 1.3. Adherence to the NMDA
189 This document in compliant with the Network Management Datastore
190 Architecture (NMDA) [RFC8342]. It does not define any protocol
191 accessible nodes that are "config false".
193 2. The "ietf-tcp-common" Module
195 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp-
196 common". A high-level overview of the module is provided in
197 Section 2.1. Examples illustatrating the module's use are provided
198 in Examples (Section 2.2). The YANG module itself is defined in
199 Section 2.3.
201 2.1. Data Model Overview
203 This section provides an overview of the "ietf-tcp-common" module in
204 terms of its features and groupings.
206 2.1.1. Model Scope
208 This document defines a common "grouping" statement for basic TCP
209 connection parameters that matter to applications. In some TCP
210 stacks, such parameters can also directly be set by an application
211 using system calls, such as the socket API. The base YANG model in
212 this document focuses on modeling TCP keep-alives. This base model
213 can be extended as needed.
215 2.1.2. Features
217 The following diagram lists all the "feature" statements defined in
218 the "ietf-tcp-common" module:
220 Features:
221 +-- keepalives-supported
223 | The diagram above uses syntax that is similar to but not
224 | defined in [RFC8340].
226 2.1.3. Groupings
228 The "ietf-tcp-common" module defines the following "grouping"
229 statements:
231 * tcp-common-grouping
232 * tcp-connection-grouping
234 These groupings are presented in the following subsections.
236 2.1.3.1. The "tcp-common-grouping" Grouping
238 The following tree diagram [RFC8340] illustrates the "tcp-common-
239 grouping" grouping:
241 grouping tcp-common-grouping
242 +-- keepalives! {keepalives-supported}?
243 +-- idle-time uint16
244 +-- max-probes uint16
245 +-- probe-interval uint16
247 Comments:
249 * The "keepalives" node is a "presence" node so that the decendent
250 nodes' "mandatory true" doesn't imply that keepalives must be
251 configured.
253 * The "idle-time", "max-probes", and "probe-interval" nodes have the
254 common meanings. Please see the YANG module in Section 2.3 for
255 details.
257 2.1.3.2. The "tcp-connection-grouping" Grouping
259 The following tree diagram [RFC8340] illustrates the "tcp-connection-
260 grouping" grouping:
262 grouping tcp-connection-grouping
263 +---u tcp-common-grouping
265 Comments:
267 * This grouping uses the "tcp-common-grouping" grouping discussed in
268 Section 2.1.3.1.
270 2.1.4. Protocol-accessible Nodes
272 The "ietf-tcp-common" module does not contain any protocol-accessible
273 nodes.
275 2.1.5. Guidelines for Configuring TCP Keep-Alives
277 Network stacks may include "keep-alives" in their TCP
278 implementations, although this practice is not universally accepted.
279 If keep-alives are included, [RFC1122] [RFC793bis] mandates that the
280 application MUST be able to turn them on or off for each TCP
281 connection, and that they MUST default to off.
283 Keep-alive mechanisms exist in many protocols. Depending on the
284 protocol stack, TCP keep-alives may only be one out of several
285 alternatives. Which mechanism(s) to use depends on the use case and
286 application requirements. If keep-alives are needed by an
287 application, it is RECOMMENDED that the aliveness check happens only
288 at the protocol layers that are meaningful to the application.
290 A TCP keep-alive mechanism SHOULD only be invoked in server
291 applications that might otherwise hang indefinitely and consume
292 resources unnecessarily if a client crashes or aborts a connection
293 during a network failure [RFC1122]. TCP keep-alives may consume
294 significant resources both in the network and in endpoints (e.g.,
295 battery power). In addition, frequent keep-alives risk network
296 congestion. The higher the frequency of keep-alives, the higher the
297 overhead.
299 Given the cost of keep-alives, parameters have to be configured
300 carefully:
302 * The default idle interval (leaf "idle-time") MUST default to no
303 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value
304 MAY be configured, but keep-alive messages SHOULD NOT be
305 transmitted more frequently than once every 15 seconds. Longer
306 intervals SHOULD be used when possible.
308 * The maximum number of sequential keep-alive probes that can fail
309 (leaf "max-probes") trades off responsiveness and robustness
310 against packet loss. ACK segments that contain no data are not
311 reliably transmitted by TCP. Consequently, if a keep-alive
312 mechanism is implemented it MUST NOT interpret failure to respond
313 to any specific probe as a dead connection [RFC1122]. Typically a
314 single-digit number should suffice.
316 * TCP implementations may include a parameter for the number of
317 seconds between TCP keep-alive probes (leaf "probe-interval"). In
318 order to avoid congestion, the time interval between probes MUST
319 NOT be smaller than one second. Significantly longer intervals
320 SHOULD be used. It is important to note that keep-alive probes
321 (or replies) can get dropped due to network congestion. Sending
322 further probe messages into a congested path after a short
323 interval, without backing off timers, could cause harm and result
324 in a congestion collapse. Therefore it is essential to pick a
325 large, conservative value for this interval.
327 2.2. Example Usage
329 This section presents an example showing the "tcp-common-grouping"
330 populated with some data.
332
333
334 15
335 3
336 30
337
338
340 2.3. YANG Module
342 The ietf-tcp-common YANG module references [RFC6991].
344 file "ietf-tcp-common@2021-02-10.yang"
346 module ietf-tcp-common {
347 yang-version 1.1;
348 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
349 prefix tcpcmn;
351 organization
352 "IETF NETCONF (Network Configuration) Working Group and the
353 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
355 contact
356 "WG Web:
357
358 WG List:
359
360 Authors: Kent Watsen
361 Michael Scharf
362 ";
364 description
365 "This module defines reusable groupings for TCP commons that
366 can be used as a basis for specific TCP common instances.
368 Copyright (c) 2020 IETF Trust and the persons identified
369 as authors of the code. All rights reserved.
371 Redistribution and use in source and binary forms, with
372 or without modification, is permitted pursuant to, and
373 subject to the license terms contained in, the Simplified
374 BSD License set forth in Section 4.c of the IETF Trust's
375 Legal Provisions Relating to IETF Documents
376 (https://trustee.ietf.org/license-info).
378 This version of this YANG module is part of RFC DDDD
379 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
380 itself for full legal notices.
382 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
383 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
384 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
385 are to be interpreted as described in BCP 14 (RFC 2119)
386 (RFC 8174) when, and only when, they appear in all
387 capitals, as shown here.";
389 revision 2021-02-10 {
390 description
391 "Initial version";
392 reference
393 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
394 }
396 // Features
397 feature keepalives-supported {
398 description
399 "Indicates that keepalives are supported.";
400 }
402 // Groupings
404 grouping tcp-common-grouping {
405 description
406 "A reusable grouping for configuring TCP parameters common
407 to TCP connections as well as the operating system as a
408 whole.";
409 container keepalives {
410 if-feature "keepalives-supported";
411 presence
412 "Indicates that keepalives are enabled. Present so that
413 the decendant nodes' 'mandatory true' doesn't imply that
414 this node must be configured.";
415 description
416 "Configures the keep-alive policy, to proactively test the
417 aliveness of the TCP peer. An unresponsive TCP peer is
418 dropped after approximately (idle-time + max-probes
419 * probe-interval) seconds.";
420 leaf idle-time {
421 type uint16 {
422 range "1..max";
423 }
424 units "seconds";
425 mandatory true;
426 description
427 "Sets the amount of time after which if no data has been
428 received from the TCP peer, a TCP-level probe message
429 will be sent to test the aliveness of the TCP peer.
430 Two hours (7200 seconds) is safe value, per RFC 1122.";
431 reference
432 "RFC 1122:
433 Requirements for Internet Hosts -- Communication Layers";
434 }
435 leaf max-probes {
436 type uint16 {
437 range "1..max";
438 }
439 mandatory true;
440 description
441 "Sets the maximum number of sequential keep-alive probes
442 that can fail to obtain a response from the TCP peer
443 before assuming the TCP peer is no longer alive.";
444 }
445 leaf probe-interval {
446 type uint16 {
447 range "1..max";
448 }
449 units "seconds";
450 mandatory true;
451 description
452 "Sets the time interval between failed probes. The interval
453 SHOULD be significantly longer than one second in order to
454 avoid harm on a congested link.";
455 }
456 } // container keepalives
457 } // grouping tcp-common-grouping
459 grouping tcp-connection-grouping {
460 description
461 "A reusable grouping for configuring TCP parameters common
462 to TCP connections.";
463 uses tcp-common-grouping;
464 }
466 }
468
470 3. The "ietf-tcp-client" Module
472 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp-
473 client". A high-level overview of the module is provided in
474 Section 3.1. Examples illustatrating the module's use are provided
475 in Examples (Section 3.2). The YANG module itself is defined in
476 Section 3.3.
478 3.1. Data Model Overview
480 This section provides an overview of the "ietf-tcp-client" module in
481 terms of its features and groupings.
483 3.1.1. Features
485 The following diagram lists all the "feature" statements defined in
486 the "ietf-tcp-client" module:
488 Features:
489 +-- local-binding-supported
490 +-- tcp-client-keepalives
491 +-- proxy-connect
492 +-- socks5-gss-api
493 +-- socks5-username-password
495 | The diagram above uses syntax that is similar to but not
496 | defined in [RFC8340].
498 3.1.2. Groupings
500 The "ietf-tcp-client" module defines the following "grouping"
501 statement:
503 * tcp-client-grouping
505 This grouping is presented in the following subsection.
507 3.1.2.1. The "tcp-client-grouping" Grouping
509 The following tree diagram [RFC8340] illustrates the "tcp-client-
510 grouping" grouping:
512 grouping tcp-client-grouping
513 +-- remote-address inet:host
514 +-- remote-port? inet:port-number
515 +-- local-address? inet:ip-address
516 | {local-binding-supported}?
517 +-- local-port? inet:port-number
518 | {local-binding-supported}?
519 +-- proxy-server! {proxy-connect}?
520 | +-- (proxy-type)
521 | +--:(socks4)
522 | | +-- socks4-parameters
523 | | +-- remote-address inet:ip-address
524 | | +-- remote-port? inet:port-number
525 | +--:(socks4a)
526 | | +-- socks4a-parameters
527 | | +-- remote-address inet:host
528 | | +-- remote-port? inet:port-number
529 | +--:(socks5)
530 | +-- socks5-parameters
531 | +-- remote-address inet:host
532 | +-- remote-port? inet:port-number
533 | +-- authentication-parameters!
534 | +-- (auth-type)
535 | +--:(gss-api) {socks5-gss-api}?
536 | | +-- gss-api
537 | +--:(username-password)
538 | {socks5-username-password}?
539 | +-- username-password
540 | +-- username string
541 | +---u ct:password-grouping
542 +---u tcpcmn:tcp-connection-grouping
544 Comments:
546 * The "remote-address" node, which is mandatory, may be configured
547 as an IPv4 address, an IPv6 address, a hostname.
549 * The "remote-port" node is not mandatory, but its default value is
550 the invalid value '0', thus forcing the consuming data model to
551 refine it in order to provide it an appropriate default value.
553 * The "local-address" node, which is enabled by the "local-binding-
554 supported" feature (Section 2.1.2), may be configured as an IPv4
555 address, an IPv6 address, or a wildcard value.
557 * The "local-port" node, which is enabled by the "local-binding-
558 supported" feature (Section 2.1.2), is not mandatory. Its default
559 value is '0', indicating that the operating system can pick an
560 arbitrary port number.
562 * The "proxy-server" node is enabled by a "feature" statement and,
563 for servers that enable it, is a "presence" container so that the
564 decendent "mandatory true" choice node doesn't imply that the
565 proxt-server node must be configured.
567 * This grouping uses the "tcp-connection-grouping" grouping
568 discussed in Section 2.1.3.2.
570 3.1.3. Protocol-accessible Nodes
572 The "ietf-tcp-client" module does not contain any protocol-accessible
573 nodes.
575 3.2. Example Usage
577 This section presents two examples showing the "tcp-client-grouping"
578 populated with some data. This example shows a TCP-client configured
579 to not connect via a proxy:
581
582 www.example.com
583 443
584 0.0.0.0
585 0
586
587 15
588 3
589 30
590
591
593 This example shows a TCP-client configured to connect via a proxy:
595
596 www.example.com
597 443
598 0.0.0.0
599 0
600
601
602 proxy.my-domain.com
603 1080
604
605
606 foobar
607 secret
608
609
610
611
612
613 15
614 3
615 30
616
617
619 3.3. YANG Module
621 The ietf-tcp-client YANG module references [RFC6991].
623 file "ietf-tcp-client@2021-02-10.yang"
625 module ietf-tcp-client {
626 yang-version 1.1;
627 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
628 prefix tcpc;
630 import ietf-inet-types {
631 prefix inet;
632 reference
633 "RFC 6991: Common YANG Data Types";
634 }
636 import ietf-crypto-types {
637 prefix ct;
638 reference
639 "RFC AAAA: YANG Data Types and Groupings for Cryptography";
640 }
642 import ietf-tcp-common {
643 prefix tcpcmn;
644 reference
645 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
646 }
648 organization
649 "IETF NETCONF (Network Configuration) Working Group and the
650 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
652 contact
653 "WG Web:
654
655 WG List:
656
657 Authors: Kent Watsen
658 Michael Scharf
659 ";
661 description
662 "This module defines reusable groupings for TCP clients that
663 can be used as a basis for specific TCP client instances.
665 Copyright (c) 2020 IETF Trust and the persons identified
666 as authors of the code. All rights reserved.
668 Redistribution and use in source and binary forms, with
669 or without modification, is permitted pursuant to, and
670 subject to the license terms contained in, the Simplified
671 BSD License set forth in Section 4.c of the IETF Trust's
672 Legal Provisions Relating to IETF Documents
673 (https://trustee.ietf.org/license-info).
675 This version of this YANG module is part of RFC DDDD
676 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
677 itself for full legal notices.
679 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
680 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
681 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
682 are to be interpreted as described in BCP 14 (RFC 2119)
683 (RFC 8174) when, and only when, they appear in all
684 capitals, as shown here.";
686 revision 2021-02-10 {
687 description
688 "Initial version";
689 reference
690 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
692 }
694 // Features
696 feature local-binding-supported {
697 description
698 "Indicates that the server supports configuring local
699 bindings (i.e., the local address and local port) for
700 TCP clients.";
701 }
703 feature tcp-client-keepalives {
704 description
705 "Per socket TCP keepalive parameters are configurable for
706 TCP clients on the server implementing this feature.";
707 }
709 feature proxy-connect {
710 description
711 "Proxy connection configuration is configurable for
712 TCP clients on the server implementing this feature.";
713 }
715 feature socks5-gss-api {
716 description
717 "Indicates that the server supports authenticating
718 using GSSAPI when initiating TCP connections via
719 and SOCKS Version 5 proxy server.";
720 reference
721 "RFC 1928: SOCKS Protocol Version 5";
722 }
724 feature socks5-username-password {
725 description
726 "Indicates that the server supports authenticating
727 using username/password when initiating TCP
728 connections via and SOCKS Version 5 proxy
729 server.";
730 reference
731 "RFC 1928: SOCKS Protocol Version 5";
732 }
734 // Groupings
736 grouping tcp-client-grouping {
737 description
738 "A reusable grouping for configuring a TCP client.
740 Note that this grouping uses fairly typical descendent
741 node names such that a stack of 'uses' statements will
742 have name conflicts. It is intended that the consuming
743 data model will resolve the issue (e.g., by wrapping
744 the 'uses' statement in a container called
745 'tcp-client-parameters'). This model purposely does
746 not do this itself so as to provide maximum flexibility
747 to consuming models.";
749 leaf remote-address {
750 type inet:host;
751 mandatory true;
752 description
753 "The IP address or hostname of the remote peer to
754 establish a connection with. If a domain name is
755 configured, then the DNS resolution should happen on
756 each connection attempt. If the DNS resolution
757 results in multiple IP addresses, the IP addresses
758 are tried according to local preference order until
759 a connection has been established or until all IP
760 addresses have failed.";
761 }
762 leaf remote-port {
763 type inet:port-number;
764 default "0";
765 description
766 "The IP port number for the remote peer to establish a
767 connection with. An invalid default value (0) is used
768 (instead of 'mandatory true') so that as application
769 level data model may 'refine' it with an application
770 specific default port number value.";
771 }
772 leaf local-address {
773 if-feature "local-binding-supported";
774 type inet:ip-address;
775 description
776 "The local IP address/interface (VRF?) to bind to for when
777 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
778 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
779 explicitly indicate the implicit default, that the server
780 can bind to any IPv4 or IPv6 addresses, respectively.";
781 }
782 leaf local-port {
783 if-feature "local-binding-supported";
784 type inet:port-number;
785 default "0";
786 description
787 "The local IP port number to bind to for when connecting
788 to the remote peer. The port number '0', which is the
789 default value, indicates that any available local port
790 number may be used.";
791 }
793 container proxy-server {
794 if-feature "proxy-connect";
795 presence
796 "Indicates that a proxy connection is configured.
797 Present so that the 'proxy-type' node's 'mandatory
798 true' doesn't imply that the proxy connection
799 must be configured.";
800 choice proxy-type {
801 mandatory true;
802 description
803 "Selects a proxy connection protocol.";
804 case socks4 {
805 container socks4-parameters {
806 leaf remote-address {
807 type inet:ip-address;
808 mandatory true;
809 description
810 "The IP address of the proxy server.";
811 }
812 leaf remote-port {
813 type inet:port-number;
814 default "1080";
815 description
816 "The IP port number for the proxy server.";
817 }
818 description
819 "Parameters for connecting to a TCP-based proxy
820 server using the SOCKS4 protocol.";
821 reference
822 "SOCKS, Proceedings: 1992 Usenix Security Symposium.";
823 }
824 }
825 case socks4a {
826 container socks4a-parameters {
827 leaf remote-address {
828 type inet:host;
829 mandatory true;
830 description
831 "The IP address or hostname of the proxy server.";
832 }
833 leaf remote-port {
834 type inet:port-number;
835 default "1080";
836 description
837 "The IP port number for the proxy server.";
838 }
839 description
840 "Parameters for connecting to a TCP-based proxy
841 server using the SOCKS4a protocol.";
842 reference
843 "SOCKS Proceedings:
844 1992 Usenix Security Symposium.
845 OpenSSH message:
846 SOCKS 4A: A Simple Extension to SOCKS 4 Protocol
847 https://www.openssh.com/txt/socks4a.protocol";
848 }
849 }
850 case socks5 {
851 container socks5-parameters {
852 leaf remote-address {
853 type inet:host;
854 mandatory true;
855 description
856 "The IP address or hostname of the proxy server.";
857 }
858 leaf remote-port {
859 type inet:port-number;
860 default "1080";
861 description
862 "The IP port number for the proxy server.";
863 }
864 container authentication-parameters {
865 presence
866 "Indicates that an authentication mechanism
867 has been configured. Present so that the
868 'auth-type' node's 'mandatory true' doesn't
869 imply that an authentication mechanism
870 must be configured.";
871 description
872 "A container for SOCKS Version 5 authentication
873 mechanisms.
875 A complete list of methods is defined at:
876 https://www.iana.org/assignments/socks-methods
877 /socks-methods.xhtml.";
878 reference
879 "RFC 1928: SOCKS Protocol Version 5";
880 choice auth-type {
881 mandatory true;
882 description
883 "A choice amongst supported SOCKS Version 5
884 authentication mechanisms.";
885 case gss-api {
886 if-feature socks5-gss-api;
887 container gss-api {
888 description
889 "Contains GSS-API configuration. Defines
890 as an empty container to enable specific
891 GSS-API configuration to be augmented in
892 by future modules.";
893 reference
894 "RFC 1928: SOCKS Protocol Version 5
895 RFC 2743: Generic Security Service
896 Application Program Interface
897 Version 2, Update 1";
898 }
899 }
900 case username-password {
901 if-feature socks5-username-password;
902 container username-password {
903 leaf username {
904 type string;
905 mandatory true;
906 description
907 "The 'username' value to use for client
908 identification.";
909 }
910 uses ct:password-grouping {
911 description
912 "The password to be used for client
913 authentication.";
914 }
915 description
916 "Contains Username/Password configuration.";
917 reference
918 "RFC 1929: Username/Password Authentication
919 for SOCKS V5";
920 }
921 }
922 }
923 }
924 description
925 "Parameters for connecting to a TCP-based proxy server
926 using the SOCKS5 protocol.";
927 reference
928 "RFC 1928: SOCKS Protocol Version 5";
929 }
930 }
931 }
932 description
933 "Proxy server settings.";
934 }
936 uses tcpcmn:tcp-connection-grouping {
937 augment "keepalives" {
938 if-feature "tcp-client-keepalives";
939 description
940 "Add an if-feature statement so that implementations
941 can choose to support TCP client keepalives.";
942 }
943 }
944 }
945 }
947
949 4. The "ietf-tcp-server" Module
951 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp-
952 server". A high-level overview of the module is provided in
953 Section 4.1. Examples illustatrating the module's use are provided
954 in Examples (Section 4.2). The YANG module itself is defined in
955 Section 4.3.
957 4.1. Data Model Overview
959 This section provides an overview of the "ietf-tcp-server" module in
960 terms of its features and groupings.
962 4.1.1. Features
964 The following diagram lists all the "feature" statements defined in
965 the "ietf-tcp-server" module:
967 Features:
968 +-- tcp-server-keepalives
970 | The diagram above uses syntax that is similar to but not
971 | defined in [RFC8340].
973 4.1.2. Groupings
975 The "ietf-tcp-server" module defines the following "grouping"
976 statement:
978 * tcp-server-grouping
979 This grouping is presented in the following subsection.
981 4.1.2.1. The "tcp-server-grouping" Grouping
983 The following tree diagram [RFC8340] illustrates the "tcp-server-
984 grouping" grouping:
986 grouping tcp-server-grouping
987 +-- local-address inet:ip-address
988 +-- local-port? inet:port-number
989 +---u tcpcmn:tcp-connection-grouping
991 Comments:
993 * The "local-address" node, which is mandatory, may be configured as
994 an IPv4 address, an IPv6 address, or a wildcard value.
996 * The "local-port" node is not mandatory, but its default value is
997 the invalid value '0', thus forcing the consuming data model to
998 refine it in order to provide it an appropriate default value.
1000 * This grouping uses the "tcp-connection-grouping" grouping
1001 discussed in Section 2.1.3.2.
1003 4.1.3. Protocol-accessible Nodes
1005 The "ietf-tcp-server" module does not contain any protocol-accessible
1006 nodes.
1008 4.2. Example Usage
1010 This section presents an example showing the "tcp-server-grouping"
1011 populated with some data.
1013
1014 10.20.30.40
1015 7777
1016
1017 15
1018 3
1019 30
1020
1021
1023 4.3. YANG Module
1025 The ietf-tcp-server YANG module references [RFC6991].
1027 file "ietf-tcp-server@2021-02-10.yang"
1029 module ietf-tcp-server {
1030 yang-version 1.1;
1031 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
1032 prefix tcps;
1034 import ietf-inet-types {
1035 prefix inet;
1036 reference
1037 "RFC 6991: Common YANG Data Types";
1038 }
1040 import ietf-tcp-common {
1041 prefix tcpcmn;
1042 reference
1043 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
1044 }
1046 organization
1047 "IETF NETCONF (Network Configuration) Working Group and the
1048 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
1050 contact
1051 "WG Web:
1052
1053 WG List:
1054
1055 Authors: Kent Watsen
1056 Michael Scharf
1057 ";
1059 description
1060 "This module defines reusable groupings for TCP servers that
1061 can be used as a basis for specific TCP server instances.
1063 Copyright (c) 2020 IETF Trust and the persons identified
1064 as authors of the code. All rights reserved.
1066 Redistribution and use in source and binary forms, with
1067 or without modification, is permitted pursuant to, and
1068 subject to the license terms contained in, the Simplified
1069 BSD License set forth in Section 4.c of the IETF Trust's
1070 Legal Provisions Relating to IETF Documents
1071 (https://trustee.ietf.org/license-info).
1073 This version of this YANG module is part of RFC DDDD
1074 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC
1075 itself for full legal notices.
1077 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1078 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1079 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1080 are to be interpreted as described in BCP 14 (RFC 2119)
1081 (RFC 8174) when, and only when, they appear in all
1082 capitals, as shown here.";
1084 revision 2021-02-10 {
1085 description
1086 "Initial version";
1087 reference
1088 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers";
1089 }
1091 // Features
1093 feature tcp-server-keepalives {
1094 description
1095 "Per socket TCP keepalive parameters are configurable for
1096 TCP servers on the server implementing this feature.";
1097 }
1099 // Groupings
1101 grouping tcp-server-grouping {
1102 description
1103 "A reusable grouping for configuring a TCP server.
1105 Note that this grouping uses fairly typical descendent
1106 node names such that a stack of 'uses' statements will
1107 have name conflicts. It is intended that the consuming
1108 data model will resolve the issue (e.g., by wrapping
1109 the 'uses' statement in a container called
1110 'tcp-server-parameters'). This model purposely does
1111 not do this itself so as to provide maximum flexibility
1112 to consuming models.";
1113 leaf local-address {
1114 type inet:ip-address;
1115 mandatory true;
1116 description
1117 "The local IP address to listen on for incoming
1118 TCP client connections. INADDR_ANY (0.0.0.0) or
1119 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
1120 used when the server is to listen on all IPv4 or
1121 IPv6 addresses, respectively.";
1123 }
1124 leaf local-port {
1125 type inet:port-number;
1126 default "0";
1127 description
1128 "The local port number to listen on for incoming TCP
1129 client connections. An invalid default value (0)
1130 is used (instead of 'mandatory true') so that an
1131 application level data model may 'refine' it with
1132 an application specific default port number value.";
1133 }
1134 uses tcpcmn:tcp-connection-grouping {
1135 augment "keepalives" {
1136 if-feature "tcp-server-keepalives";
1137 description
1138 "Add an if-feature statement so that implementations
1139 can choose to support TCP server keepalives.";
1140 }
1141 }
1142 }
1143 }
1145
1147 5. Security Considerations
1149 5.1. The "ietf-tcp-common" YANG Module
1151 The "ietf-tcp-common" YANG module defines "grouping" statements that
1152 are designed to be accessed via YANG based management protocols, such
1153 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1154 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1155 with mutual authentication.
1157 The NETCONF access control model (NACM) [RFC8341] provides the means
1158 to restrict access for particular users to a pre-configured subset of
1159 all available protocol operations and content.
1161 Since the module in this document only define groupings, these
1162 considerations are primarily for the designers of other modules that
1163 use these groupings.
1165 None of the readable data nodes defined in this YANG module are
1166 considered sensitive or vulnerable in network environments. The NACM
1167 "default-deny-all" extension has not been set for any data nodes
1168 defined in this module.
1170 None of the writable data nodes defined in this YANG module are
1171 considered sensitive or vulnerable in network environments. The NACM
1172 "default-deny-write" extension has not been set for any data nodes
1173 defined in this module.
1175 This module does not define any RPCs, actions, or notifications, and
1176 thus the security consideration for such is not provided here.
1178 5.2. The "ietf-tcp-client" YANG Module
1180 The "ietf-tcp-client" YANG module defines "grouping" statements that
1181 are designed to be accessed via YANG based management protocols, such
1182 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1183 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1184 with mutual authentication.
1186 The NETCONF access control model (NACM) [RFC8341] provides the means
1187 to restrict access for particular users to a pre-configured subset of
1188 all available protocol operations and content.
1190 Since the module in this document only define groupings, these
1191 considerations are primarily for the designers of other modules that
1192 use these groupings.
1194 One readable data node defined in this YANG module may be considered
1195 sensitive or vulnerable in some network environments. This node is
1196 as follows:
1198 * The "proxy-server/socks5-parameters/authentication-parameters/
1199 username-password/password" node:
1201 The cleartext "password" node defined in the "tcp-client-
1202 grouping" grouping is additionally sensitive to read operations
1203 such that, in normal use cases, it should never be returned to
1204 a client. For this reason, the NACM extension "default-deny-
1205 all" has been applied to it.
1207 None of the writable data nodes defined in this YANG module are
1208 considered sensitive or vulnerable in network environments. The NACM
1209 "default-deny-write" extension has not been set for any data nodes
1210 defined in this module.
1212 This module does not define any RPCs, actions, or notifications, and
1213 thus the security consideration for such is not provided here.
1215 5.3. The "ietf-tcp-server" YANG Module
1217 The "ietf-tcp-server" YANG module defines "grouping" statements that
1218 are designed to be accessed via YANG based management protocols, such
1219 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
1220 have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
1221 with mutual authentication.
1223 The NETCONF access control model (NACM) [RFC8341] provides the means
1224 to restrict access for particular users to a pre-configured subset of
1225 all available protocol operations and content.
1227 Since the module in this document only define groupings, these
1228 considerations are primarily for the designers of other modules that
1229 use these groupings.
1231 None of the readable data nodes defined in this YANG module are
1232 considered sensitive or vulnerable in network environments. The NACM
1233 "default-deny-all" extension has not been set for any data nodes
1234 defined in this module.
1236 None of the writable data nodes defined in this YANG module are
1237 considered sensitive or vulnerable in network environments. The NACM
1238 "default-deny-write" extension has not been set for any data nodes
1239 defined in this module.
1241 This module does not define any RPCs, actions, or notifications, and
1242 thus the security consideration for such is not provided here.
1244 6. IANA Considerations
1246 6.1. The "IETF XML" Registry
1248 This document registers two URIs in the "ns" subregistry of the IETF
1249 XML Registry [RFC3688]. Following the format in [RFC3688], the
1250 following registrations are requested:
1252 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common
1253 Registrant Contact: The IESG
1254 XML: N/A, the requested URI is an XML namespace.
1256 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
1257 Registrant Contact: The IESG
1258 XML: N/A, the requested URI is an XML namespace.
1260 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
1261 Registrant Contact: The IESG
1262 XML: N/A, the requested URI is an XML namespace.
1264 6.2. The "YANG Module Names" Registry
1266 This document registers two YANG modules in the YANG Module Names
1267 registry [RFC6020]. Following the format in [RFC6020], the following
1268 registrations are requested:
1270 name: ietf-tcp-common
1271 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
1272 prefix: tcpcmn
1273 reference: RFC DDDD
1275 name: ietf-tcp-client
1276 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
1277 prefix: tcpc
1278 reference: RFC DDDD
1280 name: ietf-tcp-server
1281 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
1282 prefix: tcps
1283 reference: RFC DDDD
1285 7. References
1287 7.1. Normative References
1289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1290 Requirement Levels", BCP 14, RFC 2119,
1291 DOI 10.17487/RFC2119, March 1997,
1292 .
1294 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1295 the Network Configuration Protocol (NETCONF)", RFC 6020,
1296 DOI 10.17487/RFC6020, October 2010,
1297 .
1299 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1300 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1301 .
1303 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1304 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1305 .
1307 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1308 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1309 May 2017, .
1311 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1312 Access Control Model", STD 91, RFC 8341,
1313 DOI 10.17487/RFC8341, March 2018,
1314 .
1316 7.2. Informative References
1318 [I-D.ietf-netconf-crypto-types]
1319 Watsen, K., "YANG Data Types and Groupings for
1320 Cryptography", Work in Progress, Internet-Draft, draft-
1321 ietf-netconf-crypto-types-18, 20 August 2020,
1322 .
1325 [I-D.ietf-netconf-http-client-server]
1326 Watsen, K., "YANG Groupings for HTTP Clients and HTTP
1327 Servers", Work in Progress, Internet-Draft, draft-ietf-
1328 netconf-http-client-server-05, 20 August 2020,
1329 .
1332 [I-D.ietf-netconf-keystore]
1333 Watsen, K., "A YANG Data Model for a Keystore", Work in
1334 Progress, Internet-Draft, draft-ietf-netconf-keystore-20,
1335 20 August 2020, .
1338 [I-D.ietf-netconf-netconf-client-server]
1339 Watsen, K., "NETCONF Client and Server Models", Work in
1340 Progress, Internet-Draft, draft-ietf-netconf-netconf-
1341 client-server-21, 20 August 2020,
1342 .
1345 [I-D.ietf-netconf-restconf-client-server]
1346 Watsen, K., "RESTCONF Client and Server Models", Work in
1347 Progress, Internet-Draft, draft-ietf-netconf-restconf-
1348 client-server-21, 20 August 2020,
1349 .
1352 [I-D.ietf-netconf-ssh-client-server]
1353 Watsen, K., "YANG Groupings for SSH Clients and SSH
1354 Servers", Work in Progress, Internet-Draft, draft-ietf-
1355 netconf-ssh-client-server-22, 20 August 2020,
1356 .
1359 [I-D.ietf-netconf-tcp-client-server]
1360 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients
1361 and TCP Servers", Work in Progress, Internet-Draft, draft-
1362 ietf-netconf-tcp-client-server-08, 20 August 2020,
1363 .
1366 [I-D.ietf-netconf-tls-client-server]
1367 Watsen, K., "YANG Groupings for TLS Clients and TLS
1368 Servers", Work in Progress, Internet-Draft, draft-ietf-
1369 netconf-tls-client-server-22, 20 August 2020,
1370 .
1373 [I-D.ietf-netconf-trust-anchors]
1374 Watsen, K., "A YANG Data Model for a Truststore", Work in
1375 Progress, Internet-Draft, draft-ietf-netconf-trust-
1376 anchors-13, 20 August 2020, .
1379 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1380 DOI 10.17487/RFC3688, January 2004,
1381 .
1383 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1384 and A. Bierman, Ed., "Network Configuration Protocol
1385 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1386 .
1388 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1389 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1390 .
1392 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1393 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1394 .
1396 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
1397 and R. Wilton, "Network Management Datastore Architecture
1398 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
1399 .
1401 Appendix A. Change Log
1403 This section is to be removed before publishing as an RFC.
1405 A.1. 00 to 01
1406 * Added 'local-binding-supported' feature to TCP-client model.
1408 * Added 'keepalives-supported' feature to TCP-common model.
1410 * Added 'external-endpoint-values' container and 'external-
1411 endpoints' feature to TCP-server model.
1413 A.2. 01 to 02
1415 * Removed the 'external-endpoint-values' container and 'external-
1416 endpoints' feature from the TCP-server model.
1418 A.3. 02 to 03
1420 * Moved the common model section to be before the client and server
1421 specific sections.
1423 * Added sections "Model Scope" and "Usage Guidelines for Configuring
1424 TCP Keep-Alives" to the common model section.
1426 A.4. 03 to 04
1428 * Fixed a few typos.
1430 A.5. 04 to 05
1432 * Removed commented out "grouping tcp-system-grouping" statement
1433 kept for reviewers.
1435 * Added a "Note to Reviewers" note to first page.
1437 A.6. 05 to 06
1439 * Added support for TCP proxies.
1441 A.7. 06 to 07
1443 * Expanded "Data Model Overview section(s) [remove "wall" of tree
1444 diagrams].
1446 * Updated the Security Considerations section.
1448 A.8. 07 to 08
1450 * Added missing IANA registration for "ietf-tcp-common"
1452 * Added "mandatory true" for the "username" and "password" leafs
1453 * Added an example of a TCP-client configured to connect via a proxy
1455 * Fixed issues found by the SecDir review of the "keystore" draft.
1457 * Updated the "ietf-tcp-client" module to use the new "password-
1458 grouping" grouping from the "crypto-types" module.
1460 A.9. 08 to 09
1462 * Addressed comments raised by YANG Doctor in the ct/ts/ks drafts.
1464 Authors' Addresses
1466 Kent Watsen
1467 Watsen Networks
1469 Email: kent+ietf@watsen.net
1471 Michael Scharf
1472 Hochschule Esslingen - University of Applied Sciences
1474 Email: michael.scharf@hs-esslingen.de