rfc9643.original.xml   rfc9643.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
<?rfc sortrefs="yes" ?> submissionType="IETF" docName="draft-ietf-netconf-tcp-client-server-26" number="
<?rfc compact="yes"?> 9643" updates="" obsoletes="" ipr="trust200902" tocInclude="true" symRefs="true"
<?rfc subcompact="no"?> sortRefs="true" version="3" xml:lang="en">
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
submissionType="IETF" docName="draft-ietf-netconf-tcp-client-server-26" ipr="tru
st200902" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="Groupings for TCP Clients and Servers">YANG Groupings for <title abbrev="Groupings for TCP Clients and Servers">YANG Groupings for
TCP Clients and TCP Servers</title> TCP Clients and TCP Servers</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-tcp-client-serve r-26"/> <seriesInfo name="RFC" value="9643"/>
<author fullname="Kent Watsen" initials="K." surname="Watsen"> <author fullname="Kent Watsen" initials="K." surname="Watsen">
<organization>Watsen Networks</organization> <organization>Watsen Networks</organization>
<address> <address>
<email>kent+ietf@watsen.net</email> <email>kent+ietf@watsen.net</email>
</address> </address>
</author> </author>
<author fullname="Michael Scharf" initials="M." surname="Scharf"> <author fullname="Michael Scharf" initials="M." surname="Scharf">
<organization abbrev="Hochschule Esslingen"> <organization abbrev="Hochschule Esslingen">
Hochschule Esslingen - University of Applied Sciences Hochschule Esslingen
</organization> </organization>
<address> <address>
<postal>
<street>University of Applied Sciences</street>
<street>Kanalstr. 33</street>
<code>73728</code>
<city>Esslingen am Neckar</city>
<country>Germany</country>
</postal>
<email>michael.scharf@hs-esslingen.de</email> <email>michael.scharf@hs-esslingen.de</email>
</address> </address>
</author> </author>
<date/> <date month="October" year="2024"/>
<area>Operations</area> <area>OPS</area>
<workgroup>NETCONF Working Group</workgroup> <workgroup>netconf</workgroup>
<keyword>IETF</keyword>
<abstract> <abstract>
<t>This document presents three YANG 1.1 modules <t>This document presents three YANG 1.1 modules
to support the configuration of TCP clients and TCP servers. The modules to support the configuration of TCP clients and TCP servers. The modules
include basic parameters of a TCP connection relevant for client or serv er include basic parameters of a TCP connection relevant for client or serv er
applications, as well as client configuration required for traversing pr oxies. applications, as well as client configuration required for traversing pr oxies.
The modules can be used either standalone or in conjunction with configu The data models defined by these modules may be used directly (e.g., to
ration define a specific TCP-client or TCP-server) or in conjunction with the configura
of other stack protocol layers.</t> tion defined for higher level protocols that depend on TCP (e.g., SSH, TLS, etc.
). Examples of higher level protocol configuration designed to be used in conju
nction with this configuration are in RFCs 9644 and 9645.</t>
</abstract> </abstract>
<note>
<name>Editorial Note (To be removed by RFC Editor)</name>
<t>This draft contains placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.</t>
<t>Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
</t>
<ul spacing="normal">
<li>
<tt>AAAA</tt> --&gt; the assigned RFC value for draft-ietf-netconf-cry
pto-types</li>
<li>
<tt>DDDD</tt> --&gt; the assigned RFC value for this draft</li>
</ul>
<t>Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement:
</t>
<ul spacing="normal">
<li>
<tt>2024-04-04</tt> --&gt; the publication date of this draft</li>
</ul>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/>
contains
the text "one or more YANG modules" and, later, "modules". This text is
sourced
from a file in a context where it is unknown how many modules a draft de
fines.
The text is not wrong as is, but it may be improved by stating more dire
ctly how
many modules are defined.</t>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/>
contains
a self-reference to this draft, along with a corresponding reference i
n
the Appendix. Please replace the self-reference in this section with
"This RFC"
(or similar) and remove the self-reference in the "Normative/Informati
ve References"
section, whichever it is in.</t>
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined i
n RFC 8792.
However, nicer-to-the-eye is when the '\\' line-folding mode is used.
The AD suggested
suggested putting a request here for the RFC Editor to help convert "u
gly" '\' folded
examples to use the '\\' folding mode. "Help convert" may be interpre
ted as, identify
what looks ugly and ask the authors to make the adjustment.</t>
<t>The following Appendix section is to be removed prior to publication:
</t>
<ul spacing="normal">
<li>
<xref target="change-log"/>. Change Log</li>
</ul>
</note>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t>This document defines three YANG 1.1 <xref target="RFC7950"/> modules <t>This document defines three YANG 1.1 <xref target="RFC7950"/> modules
to support the configuration of TCP clients and TCP servers (TCP is to support the configuration of TCP clients and TCP servers (TCP is
defined in <xref target="RFC9293"/>), either as standalone or in defined in <xref target="RFC9293"/>). The data models defined by these m
conjunction with configuration of other stack protocol layers.</t> odules may be used directly (e.g., to define a specific TCP-client or TCP-server
) or in conjunction with the configuration defined for higher level protocols th
at depend on TCP (e.g., SSH, TLS, etc.). Examples of higher level protocol conf
iguration designed to be used in conjunction with this configuration are in <xre
f target="RFC9644"/> and <xref target="RFC9645"/>.</t>
<t>The modules focus on three different types of base TCP parameters that matter <t>The modules focus on three different types of base TCP parameters that matter
for TCP-based applications: First, the modules cover fundamental configu ration of a for TCP-based applications: First, the modules cover fundamental configu ration of a
TCP client or TCP server application, such as addresses and port numbers . Second, a TCP client or TCP server application, such as addresses and port numbers . Second, a
reusable grouping enables modification of application-specific parameter reusable grouping enables modification of application-specific parameter
s for a TCP s for TCP
connections, such as use of TCP keep-alives. And third, client configura connections, such as use of TCP keepalives. And third, client configurat
tion for ion for
traversing proxies is included as well. In each case, the modules have a very narrow traversing proxies is included as well. In each case, the modules have a very narrow
scope and focus on a minimum set of required parameters.</t> scope and focus on a minimum set of required parameters.</t>
<t>Please be advised that while this document presents support for some TC P <t>Please be advised that while this document presents support for some TC P
proxy techniques, there are other TCP proxy techniques that are not part proxy techniques, there are other TCP proxy techniques that are not part
of this document, but could be added by augmenting the YANG module.</t> of this document but could be added by augmenting the YANG module.</t>
<section anchor="collective-effort"> <section anchor="collective-effort">
<name>Relation to other RFCs</name> <name>Relation to Other RFCs</name>
<t>This document presents one or more YANG modules <xref target="RFC7950 <t>This document presents three YANG modules <xref target="RFC7950"/>
"/>
that are part of a collection of RFCs that work together that are part of a collection of RFCs that work together
to, ultimately, support the configuration of both the clients to ultimately support the configuration of both the clients
and servers of both the NETCONF <xref target="RFC6241"/> and and servers of both the Network Configuration Protocol (NETCONF) <xr
RESTCONF <xref target="RFC8040"/> protocols.</t> ef target="RFC6241"/> and
RESTCONF <xref target="RFC8040"/>.</t>
<t> The dependency relationship between the primary YANG groupings <t> The dependency relationship between the primary YANG groupings
defined in the various RFCs is presented in the below diagram. defined in the various RFCs is presented in the below diagram.
In some cases, a draft may define secondary groupings that In some cases, a document may define secondary groupings that
introduce dependencies not illustrated in the diagram. introduce dependencies not illustrated in the diagram.
The labels in the diagram are a shorthand name for the defining The labels in the diagram are shorthand names for the defining
RFC. The citation reference for shorthand name is provided below RFCs. The citation references for shorthand names are provided belo
w
the diagram.</t> the diagram.</t>
<t>Please note that the arrows in the diagram point from referencer <t>Please note that the arrows in the diagram point from referencer
to referenced. For example, the "crypto-types" RFC does not to referenced. For example, the "crypto-types" RFC does not
have any dependencies, whilst the "keystore" RFC depends on the have any dependencies, whilst the "keystore" RFC depends on the
"crypto-types" RFC.</t> "crypto-types" RFC.</t>
<artwork><![CDATA[ <artwork><![CDATA[
crypto-types crypto-types
^ ^ ^ ^
/ \ / \
/ \ / \
skipping to change at line 157 skipping to change at line 110
| | | +-----+ +---------+ | | | | +-----+ +---------+ |
| | | | | | | | | | | |
| +-----------|--------|--------------+ | | | +-----------|--------|--------------+ | |
| | | | | | | | | | | |
+-----------+ | | | | | +-----------+ | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
netconf-client-server restconf-client-server netconf-client-server restconf-client-server
]]></artwork> ]]></artwork>
<!-- RFC Editor: is there anyway to flush-left the table in PDF/HTML vie
ws? --> <table align="left">
<table>
<name>Label in Diagram to RFC Mapping</name> <name>Label in Diagram to RFC Mapping</name>
<tbody> <tbody>
<tr> <tr>
<th>Label in Diagram</th> <th>Label in Diagram</th>
<th>Originating RFC</th> <th>Reference</th>
</tr> </tr>
<tr> <tr>
<td>crypto-types</td> <td>crypto-types</td>
<td> <td>
<xref target="I-D.ietf-netconf-crypto-types"/></td> <xref target="RFC9640"/></td>
</tr> </tr>
<tr> <tr>
<td>truststore</td> <td>truststore</td>
<td> <td>
<xref target="I-D.ietf-netconf-trust-anchors"/></td> <xref target="RFC9641"/></td>
</tr> </tr>
<tr> <tr>
<td>keystore</td> <td>keystore</td>
<td> <td>
<xref target="I-D.ietf-netconf-keystore"/></td> <xref target="RFC9642"/></td>
</tr> </tr>
<tr> <tr>
<td>tcp-client-server</td> <td>tcp-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-tcp-client-server"/></td> RFC 9643</td>
</tr> </tr>
<tr> <tr>
<td>ssh-client-server</td> <td>ssh-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-ssh-client-server"/></td> <xref target="RFC9644"/></td>
</tr> </tr>
<tr> <tr>
<td>tls-client-server</td> <td>tls-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-tls-client-server"/></td> <xref target="RFC9645"/></td>
</tr> </tr>
<tr> <tr>
<td>http-client-server</td> <td>http-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-http-client-server"/></td> <xref target="I-D.ietf-netconf-http-client-server"/></td>
</tr> </tr>
<tr> <tr>
<td>netconf-client-server</td> <td>netconf-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-netconf-client-server"/></td> <xref target="I-D.ietf-netconf-netconf-client-server"/></td>
skipping to change at line 215 skipping to change at line 168
<tr> <tr>
<td>restconf-client-server</td> <td>restconf-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-restconf-client-server"/></td> <xref target="I-D.ietf-netconf-restconf-client-server"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section>
<name>Specification Language</name> <name>Specification Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/ NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section> <section>
<name>Adherence to the NMDA</name> <name>Adherence to the NMDA</name>
<t>This document is compliant with the Network Management Datastore <t>This document is compliant with the Network Management Datastore
Architecture (NMDA) <xref target="RFC8342"/>. It does not define Architecture (NMDA) <xref target="RFC8342"/>. It does not define
any protocol accessible nodes that are "config false".</t> any protocol accessible nodes that are "config false".</t>
</section> </section>
<section>
<name>Conventions</name>
<t> Various examples in this document use the XML
<xref target="W3C.REC-xml-20081126"/> encoding. Other encodings, such as JSON
<xref target="RFC8259"/>,
could alternatively be used.
</t>
</section>
</section> </section>
<section anchor="tcp-common-model"> <section anchor="tcp-common-model">
<name>The "ietf-tcp-common" Module</name> <name>The "ietf-tcp-common" Module</name>
<t>This section defines a YANG 1.1 module called <t>This section defines a YANG 1.1 module called
"ietf-tcp-common". A high-level overview of the module is provided in "ietf-tcp-common". A high-level overview of the module is provided in
<xref target="common-overview"/>. Examples illustrating the module's use <xref target="common-overview"/>. Examples illustrating the module's use
are provided in <xref target="common-examples">Examples</xref>. The YANG are provided in <xref target="common-examples"/> ("Example Usage"). The YANG
module itself is defined in <xref target="common-yang-module"/>.</t> module itself is defined in <xref target="common-yang-module"/>.</t>
<section anchor="common-overview"> <section anchor="common-overview">
<name>Data Model Overview</name> <name>Data Model Overview</name>
<t>This section provides an overview of the "ietf-tcp-common" module <t>This section provides an overview of the "ietf-tcp-common" module
in terms of its features and groupings.</t> in terms of its features and groupings.</t>
<section toc="exclude"> <section toc="exclude">
<name>Model Scope</name> <name>Model Scope</name>
<t>This document presents a common "grouping" statement for basic TCP connection <t>This document presents a common "grouping" statement for basic TCP connection
parameters that matter to applications. It is "common" in that this grouping parameters that matter to applications. It is "common" in that this grouping
is used by both the "ietf-tcp-client" and "ietf-tcp-server" modules. In some is used by both the "ietf-tcp-client" and "ietf-tcp-server" modules. In some
TCP stacks, such parameters can also directly be set by an applicati on using TCP stacks, such parameters can also directly be set by an applicati on using
system calls, such as the sockets API. The base YANG model in this d system calls, such as the sockets API. The base YANG data model in t
ocument his document
focuses on modeling TCP keep-alives. This base model can be extended focuses on modeling TCP keepalives. This base model can be extended
as needed.</t> as needed.</t>
</section> </section>
<section anchor="common-features" toc="exclude"> <section anchor="common-features" toc="exclude">
<name>Features</name> <name>Features</name>
<t>The following diagram lists all the "feature" statements <t>The following diagram lists all the "feature" statements
defined in the "ietf-tcp-common" module:</t> defined in the "ietf-tcp-common" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Features: Features:
+-- keepalives-supported +-- keepalives-supported
]]></artwork> ]]></sourcecode>
<!--<aside>--> <!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340"/>.</t>
<!--</aside>--> <!--</aside>-->
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Groupings</name> <name>Groupings</name>
<t>The "ietf-tcp-common" module defines the following "grouping" state ment:</t> <t>The "ietf-tcp-common" module defines the following "grouping" state ment:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>tcp-common-grouping</li> <li>tcp-common-grouping</li>
</ul> </ul>
<t>This grouping is presented in the following subsection.</t> <t>This grouping is presented in the following subsection.</t>
<section anchor="tcp-common-grouping"> <section anchor="tcp-common-grouping">
<name>The "tcp-common-grouping" Grouping</name> <name>The "tcp-common-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"tcp-common-grouping" grouping:</t> "tcp-common-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping tcp-common-grouping: grouping tcp-common-grouping:
+-- keepalives! {keepalives-supported}? +-- keepalives! {keepalives-supported}?
+-- idle-time? uint16 +-- idle-time? uint16
+-- max-probes? uint16 +-- max-probes? uint16
+-- probe-interval? uint16 +-- probe-interval? uint16
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "keepalives" node is a "presence" container so that the ma ndatory descendant nodes <li>The "keepalives" node is a "presence" container so that the ma ndatory descendant nodes
do not imply that keepalives must be configured.</li> do not imply that keepalives must be configured.</li>
<li>The "idle-time", "max-probes", and "probe-interval" nodes have the <li>The "idle-time", "max-probes", and "probe-interval" nodes have the
common meanings. Please see the YANG module in <xref target="co mmon-yang-module"/> common meanings. Please see the YANG module in <xref target="co mmon-yang-module"/>
for details.</li> for details.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Protocol-accessible Nodes</name> <name>Protocol-Accessible Nodes</name>
<t>The "ietf-tcp-common" module defines only "grouping" statements tha t are used by <t>The "ietf-tcp-common" module defines only "grouping" statements tha t are used by
other modules to instantiate protocol-accessible nodes. Thus this m odule, when other modules to instantiate protocol-accessible nodes. Thus, this module, when
implemented, does not itself define any protocol-accessible nodes.</ t> implemented, does not itself define any protocol-accessible nodes.</ t>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Guidelines for Configuring TCP Keep-Alives</name> <name>Guidelines for Configuring TCP Keepalives</name>
<t>Network stacks may include "keep-alives" in their TCP implementatio <t>Network stacks may include keepalives in their TCP implementations,
ns, although this practice is not universally implemented. If keepalives a
although this practice is not universally implemented. If keep-alive re
s are included, <xref target="RFC9293"/> mandates that the application <bc
included, <xref target="RFC9293"/> mandates that the application MUS p14>MUST</bcp14> be
T be able to turn them on or off for each TCP connection and that they <b
able to turn them on or off for each TCP connection, and that they M cp14>MUST</bcp14>
UST
default to off.</t> default to off.</t>
<t>Keep-alive mechanisms exist in many protocols. Depending on the pro <t>Keepalive mechanisms exist in many protocols. Depending on the prot
tocol ocol
stack, TCP keep-alives may only be one out of several alternatives. stack, TCP keepalives may only be one out of several alternatives.
Which Which
mechanism(s) to use depends on the use case and application requirem ents. If mechanism(s) to use depends on the use case and application requirem ents. If
keep-alives are needed by an application, it is RECOMMENDED that the keepalives are needed by an application, it is <bcp14>RECOMMENDED</b cp14> that the
liveness check happens only at the protocol layers that are meaningf ul liveness check happens only at the protocol layers that are meaningf ul
to the application.</t> to the application.</t>
<t>A TCP keep-alive mechanism SHOULD only be invoked in server applica tions <t>A TCP keepalive mechanism <bcp14>SHOULD</bcp14> only be invoked in server applications
that might otherwise hang indefinitely and consume resources unneces sarily that might otherwise hang indefinitely and consume resources unneces sarily
if a client crashes or aborts a connection during a network failure <xref target="RFC9293"/>. if a client crashes or aborts a connection during a network failure <xref target="RFC9293"/>.
TCP keep-alives may consume significant resources both in the networ TCP keepalives may consume significant resources both in the network
k and and
in endpoints (e.g., battery power). In addition, frequent keep-aliv in endpoints (e.g., battery power). In addition, frequent keepalive
es s
risk network congestion. The higher the frequency of keep-alives, th risk network congestion. The higher the frequency of keepalives, the
e
higher the overhead.</t> higher the overhead.</t>
<t> <t>
Given the cost of keep-alives, parameters have to be configured care fully: Given the cost of keepalives, parameters have to be configured caref ully:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The default idle interval (leaf "idle-time") is two hours, i.e., <li>The default idle interval (leaf "idle-time") is two hours, i.e.,
7200 seconds <xref target="RFC9293"/>. A lower value MAY be 7200 seconds <xref target="RFC9293"/>. A lower value <bcp14>MAY
configured, but idle intervals SHOULD NOT be smaller than 15 </bcp14> be
seconds. Longer idle intervals SHOULD be used when possible.</li configured, but idle intervals <bcp14>SHOULD NOT</bcp14> be smal
> ler than 15
<li>The maximum number of sequential keep-alive probes that can fail seconds. Longer idle intervals <bcp14>SHOULD</bcp14> be used whe
n possible.</li>
<li>The maximum number of sequential keepalive probes that can fail
(leaf "max-probes") trades off responsiveness and robustness aga inst (leaf "max-probes") trades off responsiveness and robustness aga inst
packet loss. ACK segments that contain no data are not reliably packet loss. ACK segments that contain no data are not reliably
transmitted by TCP. Consequently, if a keep-alive mechanism is transmitted by TCP. Consequently, if a keepalive mechanism is
implemented it MUST NOT interpret failure to respond to any implemented, it <bcp14>MUST NOT</bcp14> interpret failure to res
pond to any
specific probe as a dead connection <xref target="RFC9293"/>. specific probe as a dead connection <xref target="RFC9293"/>.
Typically, a single-digit number should suffice.</li> Typically, a single-digit number should suffice.</li>
<li>TCP implementations may include a parameter for the number of <li>TCP implementations may include a parameter for the number of
seconds between TCP keep-alive probes (leaf "probe-interval"). I seconds between TCP keepalive probes (leaf "probe-interval"). In
n order to avoid congestion, the time interval between probes <bcp
order to avoid congestion, the time interval between probes MUST 14>MUST NOT</bcp14>
NOT be smaller than one second. Significantly longer intervals <bcp1
be smaller than one second. Significantly longer intervals SHOUL 4>SHOULD</bcp14> be
D be used. It is important to note that keepalive probes (or replies)
used. It is important to note that keep-alive probes (or replies
)
can get dropped due to network congestion. Sending further probe can get dropped due to network congestion. Sending further probe
messages into a congested path after a short interval, without messages into a congested path after a short interval, without
backing off timers, could cause harm and result in a congestion backing off timers, could cause harm and result in a congestion
collapse. Therefore it is essential to pick a large, conservati ve collapse. Therefore, it is essential to pick a large, conservat ive
value for this interval.</li> value for this interval.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="common-examples"> <section anchor="common-examples">
<name>Example Usage</name> <name>Example Usage</name>
<t>This section presents an example showing the "tcp-common-grouping" <t>This section presents an example showing the "tcp-common-grouping" gr ouping
populated with some data.</t> populated with some data.</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
<!-- The outermost element below doesn't exist in the data model. --> <!-- The outermost element below doesn't exist in the data model. -->
<!-- It simulates if the "grouping" were a "container" instead. --> <!-- It simulates if the "grouping" were a "container" instead. -->
<tcp-common xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-common"> <tcp-common xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-common">
<keepalives> <keepalives>
<idle-time>7200</idle-time> <idle-time>7200</idle-time>
<max-probes>9</max-probes> <max-probes>9</max-probes>
<probe-interval>75</probe-interval> <probe-interval>75</probe-interval>
</keepalives> </keepalives>
</tcp-common> </tcp-common>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="common-yang-module"> <section anchor="common-yang-module">
<name>YANG Module</name> <name>YANG Module</name>
<t>The ietf-tcp-common YANG module references <xref target="RFC6991"/> <t>The "ietf-tcp-common" YANG module references <xref target="RFC6991"/>
and <xref target="RFC9293"/>.</t> and <xref target="RFC9293"/>.</t>
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-tcp-common@2024-04 <sourcecode name="ietf-tcp-common@2024-04-04.yang" type="yang" markers="
-04.yang"</t> true"><![CDATA[
<artwork><![CDATA[
module ietf-tcp-common { module ietf-tcp-common {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
prefix tcpcmn; prefix tcpcmn;
organization organization
"IETF NETCONF (Network Configuration) Working Group and the "IETF NETCONF (Network Configuration) Working Group and the
IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
https://datatracker.ietf.org/wg/tcpm https://datatracker.ietf.org/wg/tcpm
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
TCPM WG list <mailto:tcpm@ietf.org> TCPM WG list <mailto:tcpm@ietf.org>
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
Michael Scharf Michael Scharf
<mailto:michael.scharf@hs-esslingen.de>"; <mailto:michael.scharf@hs-esslingen.de>";
description description
"This module define a reusable 'grouping' that is common "This module define a reusable 'grouping' that is common
to both TCP-clients and TCP-servers. This grouping statement to both TCP clients and TCP servers. This grouping statement
is used by both the 'ietf-tcp-client' and 'ietf-tcp-server' is used by both the 'ietf-tcp-client' and 'ietf-tcp-server'
modules. modules.
Copyright (c) 2023 IETF Trust and the persons identified The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
as authors of the code. All rights reserved. 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2024 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC DDDD This version of this YANG module is part of RFC 9643
(https://www.rfc-editor.org/info/rfcDDDD); see the RFC (https://www.rfc-editor.org/info/rfc9643); see the RFC
itself for full legal notices. itself for full legal notices.";
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2024-04-04 { revision 2024-04-04 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; "RFC 9643: YANG Groupings for TCP Clients and TCP Servers";
} }
// Features // Features
feature keepalives-supported { feature keepalives-supported {
description description
"Indicates that keepalives are supported."; "Indicates that keepalives are supported.";
} }
// Groupings // Groupings
grouping tcp-common-grouping { grouping tcp-common-grouping {
description description
"A reusable grouping for configuring TCP parameters common "A reusable grouping for configuring TCP parameters common
to TCP connections as well as the operating system as a to TCP connections as well as the operating system as a
whole."; whole.";
container keepalives { container keepalives {
if-feature "keepalives-supported"; if-feature "keepalives-supported";
presence presence "Indicates that keepalives are enabled, aligning to
"Indicates that keepalives are enabled, aligning to the requirement in Section 3.8.4 of RFC 9293 that
the requirement in Section 3.8.4 RFC 9293 that states keepalives are off by default.";
keepalives are off by default.";
description description
"Configures the keep-alive policy, to proactively test the "Configures the keepalive policy to proactively test the
aliveness of the TCP peer. An unresponsive TCP peer is aliveness of the TCP peer. An unresponsive TCP peer is
dropped after approximately (idle-time + max-probes * dropped after approximately (idle-time + max-probes *
probe-interval) seconds. Further guidance can be found probe-interval) seconds. Further guidance can be found
in Section 2.1.5 of RFC DDDD."; in Section 2.1.5 of RFC 9643.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP)"; "RFC 9293: Transmission Control Protocol (TCP)";
leaf idle-time { leaf idle-time {
type uint16 { type uint16 {
range "1..max"; range "1..max";
} }
units "seconds"; units "seconds";
default 7200; default "7200";
description description
"Sets the amount of time after which if no data has been "Sets the amount of time after which a TCP-level probe
received from the TCP peer, a TCP-level probe message message will be sent to test the aliveness of the TCP
will be sent to test the aliveness of the TCP peer. peer if no data has been received from the TCP peer.
Two hours (7200 seconds) is safe value, per RFC 9293 Two hours (7200 seconds) is a safe value, per Section
Section 3.8.4."; 3.8.4 of RFC 9293.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP)"; "RFC 9293: Transmission Control Protocol (TCP)";
} }
leaf max-probes { leaf max-probes {
type uint16 { type uint16 {
range "1..max"; range "1..max";
} }
default 9; default "9";
description description
"Sets the maximum number of sequential keep-alive probes "Sets the maximum number of sequential keepalive probes
that can fail to obtain a response from the TCP peer that can fail to obtain a response from the TCP peer
before assuming the TCP peer is no longer alive."; before assuming the TCP peer is no longer alive.";
} }
leaf probe-interval { leaf probe-interval {
type uint16 { type uint16 {
range "1..max"; range "1..max";
} }
units "seconds"; units "seconds";
default 75; default "75";
description description
"Sets the time interval between failed probes. The interval "Sets the time interval between failed probes. The
SHOULD be significantly longer than one second in order to interval SHOULD be significantly longer than one second
avoid harm on a congested link."; in order to avoid harm on a congested link.";
} }
} // container keepalives } // container keepalives
} // grouping tcp-common-grouping } // grouping tcp-common-grouping
} }
]]></artwork> ]]></sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
</section> </section>
<section anchor="tcp-client-model"> <section anchor="tcp-client-model">
<name>The "ietf-tcp-client" Module</name> <name>The "ietf-tcp-client" Module</name>
<t>This section defines a YANG 1.1 module called <t>This section defines a YANG 1.1 module called
"ietf-tcp-client". A high-level overview of the module is provided in "ietf-tcp-client". A high-level overview of the module is provided in
<xref target="client-overview"/>. Examples illustrating the module's use <xref target="client-overview"/>. Examples illustrating the module's use
are provided in <xref target="client-examples">Examples</xref>. The YANG are provided in <xref target="client-examples"/> ("Example Usage"). The YANG
module itself is defined in <xref target="client-yang-module"/>.</t> module itself is defined in <xref target="client-yang-module"/>.</t>
<section anchor="client-overview"> <section anchor="client-overview">
<name>Data Model Overview</name> <name>Data Model Overview</name>
<t>This section provides an overview of the "ietf-tcp-client" module <t>This section provides an overview of the "ietf-tcp-client" module
in terms of its features and groupings.</t> in terms of its features and groupings.</t>
<section anchor="features" toc="exclude"> <section anchor="features" toc="exclude">
<name>Features</name> <name>Features</name>
<t>The following diagram lists all the "feature" statements <t>The following diagram lists all the "feature" statements
defined in the "ietf-tcp-client" module:</t> defined in the "ietf-tcp-client" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Features: Features:
+-- local-binding-supported +-- local-binding-supported
+-- tcp-client-keepalives +-- tcp-client-keepalives
+-- proxy-connect +-- proxy-connect
+-- socks4-supported {proxy-connect}? +-- socks4-supported {proxy-connect}?
+-- socks4a-supported {proxy-connect}? +-- socks4a-supported {proxy-connect}?
+-- socks5-supported {proxy-connect}? +-- socks5-supported {proxy-connect}?
+-- socks5-gss-api {socks5-supported}? +-- socks5-gss-api {socks5-supported}?
+-- socks5-username-password {socks5-supported}? +-- socks5-username-password {socks5-supported}?
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "local-binding-supported" feature indicates that <li>The "local-binding-supported" feature indicates that
the server supports configuring local bindings (i.e., the server supports configuring local bindings (i.e.,
the local address and local port) for TCP clients."</li> the local address and local port) for TCP clients.</li>
<li>The "tcp-client-keepalives" feature indicates that <li>The "tcp-client-keepalives" feature indicates that
per socket TCP keepalive parameters are configurable for TCP keepalive parameters are configurable for
TCP clients on the server implementing this feature.</li> TCP clients on the server implementing this feature.</li>
<li>The "proxy-connect" feature indicates the TCP-client <li>The "proxy-connect" feature indicates the TCP client
supports connecting through TCP proxies.</li> supports connecting through TCP proxies.</li>
<li>The "socks4-supported" feature indicates the <li>The "socks4-supported" feature indicates the
TCP-client supports Socks4-based proxies.</li> TCP client supports Socks4-based proxies.</li>
<li>The "socks4a-supported" feature indicates the <li>The "socks4a-supported" feature indicates the
TCP-client supports Socks4a-based proxies. The difference TCP client supports Socks4a-based proxies. The difference
between Socks4 and Socks4a is that Socks4a enables the between Socks4 and Socks4a is that Socks4a enables the
"remote-address" to be specified using a hostname, in "remote-address" to be specified using a hostname, in
addition to an IP address.</li> addition to an IP address.</li>
<li>The "socks5-supported" feature indicates the <li>The "socks5-supported" feature indicates the
TCP-client supports Socks5-based proxies.</li> TCP client supports Socks5-based proxies.</li>
<li>The "socks5-gss-api" feature indicates that <li>The "socks5-gss-api" feature indicates that
the server, when acting as a TCP-client, supports the server, when acting as a TCP client, supports
authenticating to a SOCKS Version 5 proxy server authenticating to a SOCKS Version 5 proxy server
using GSSAPI credentials.</li> using Generic Security Service Application Program Interface (GS S-API) credentials.</li>
<li>The "socks5-username-password" feature indicates <li>The "socks5-username-password" feature indicates
that the server, when acting as a TCP-client, that the server, when acting as a TCP client,
supports authenticating to a SOCKS Version 5 supports authenticating to a SOCKS Version 5
proxy server using 'username' and 'password' proxy server using "username" and "password"
credentials."</li> credentials."</li>
</ul> </ul>
<!--<aside>--> <!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340"/>.</t>
<!--</aside>--> <!--</aside>-->
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Groupings</name> <name>Groupings</name>
<t>The "ietf-tcp-client" module defines the following "grouping" state ment:</t> <t>The "ietf-tcp-client" module defines the following "grouping" state ment:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>tcp-client-grouping</li> <li>tcp-client-grouping</li>
</ul> </ul>
<t>This grouping is presented in the following subsection.</t> <t>This grouping is presented in the following subsection.</t>
<section anchor="tcp-client-grouping"> <section anchor="tcp-client-grouping">
<name>The "tcp-client-grouping" Grouping</name> <name>The "tcp-client-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"tcp-client-grouping" grouping:</t> "tcp-client-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping tcp-client-grouping: grouping tcp-client-grouping:
+-- remote-address inet:host +-- remote-address inet:host
+-- remote-port? inet:port-number +-- remote-port? inet:port-number
+-- local-address? inet:ip-address +-- local-address? inet:ip-address
| {local-binding-supported}? | {local-binding-supported}?
+-- local-port? inet:port-number +-- local-port? inet:port-number
| {local-binding-supported}? | {local-binding-supported}?
+-- proxy-server! {proxy-connect}? +-- proxy-server! {proxy-connect}?
| +-- (proxy-type) | +-- (proxy-type)
| +--:(socks4) {socks4-supported}? | +--:(socks4) {socks4-supported}?
skipping to change at line 593 skipping to change at line 552
| +-- authentication-parameters! | +-- authentication-parameters!
| +-- (auth-type) | +-- (auth-type)
| +--:(gss-api) {socks5-gss-api}? | +--:(gss-api) {socks5-gss-api}?
| | +-- gss-api | | +-- gss-api
| +--:(username-password) | +--:(username-password)
| {socks5-username-password}? | {socks5-username-password}?
| +-- username-password | +-- username-password
| +-- username string | +-- username string
| +---u ct:password-grouping | +---u ct:password-grouping
+---u tcpcmn:tcp-common-grouping +---u tcpcmn:tcp-common-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "remote-address" node, which is mandatory, may be configur ed as <li>The "remote-address" node, which is mandatory, may be configur ed as
an IPv4 address, an IPv6 address, or a hostname.</li> an IPv4 address, an IPv6 address, or a hostname.</li>
<li>The "remote-port" node is not mandatory, but its default value <li>The "remote-port" leaf is defined with neither a "default" nor
is a "mandatory" statement. YANG modules using this grouping <bcp14>SHOULD</bcp14>
the invalid value '0', thus forcing the consuming data model to refine the grouping
refine it in order to provide it an appropriate default value.</ with a "default" statement, when the port number is well-known (e.g., a port num
li> ber allocated by IANA), or with a
"mandatory" statement, if a port number needs to always be configured. The <bc
p14>SHOULD</bcp14> can be ignored when the port number is neither well-known nor
mandatory to configure, such as might be the case when this grouping is used by
another grouping.</li>
<li>The "local-address" node, which is enabled by the "local-bindi ng-supported" <li>The "local-address" node, which is enabled by the "local-bindi ng-supported"
feature (<xref target="common-features"/>), may be configured as feature (<xref target="features"/>), may be configured as
an IPv4 address, an IPv6 address, or a wildcard value.</li> an IPv4 address, an IPv6 address, or a wildcard value.</li>
<li>The "local-port" node, which is enabled by the "local-binding- supported" <li>The "local-port" node, which is enabled by the "local-binding- supported"
feature (<xref target="common-features"/>), is not mandatory. It feature (<xref target="features"/>), is not mandatory. Its defau
s default lt
value is '0', indicating that the operating system can pick an value is "0", indicating that the operating system can pick an
arbitrary port number.</li> arbitrary port number.</li>
<li>The "proxy-server" node is enabled by a "feature" statement an d, for <li>The "proxy-server" node is enabled by a "feature" statement an d, for
servers that enable it, is a "presence" container so that the de scendant servers that enable it, is a "presence" container so that the de scendant
"mandatory true" choice node does not imply that the proxy-serve r node "mandatory true" choice node does not imply that the proxy-serve r node
must be configured. The proxy-server node uses a "choice" state ment must be configured. The proxy-server node uses a "choice" state ment
to allow one of several types of proxies to be configured. The choices to allow one of several types of proxies to be configured. The choices
presented in this document include Socks4, Socks4a, and Socks5, each presented in this document include Socks4, Socks4a, and Socks5, each
enabled by a YANG feature (see <xref target="features"/>). Othe r proxy enabled by a YANG feature (see <xref target="features"/>). Othe r proxy
types may be added by future work.</li> types may be added by future work.</li>
<li>This grouping uses the "password-grouping" grouping discussed in <li>This grouping uses the "password-grouping" grouping discussed in
<xref target="I-D.ietf-netconf-crypto-types"/>.</li> <xref target="RFC9640"/>.</li>
<li>This grouping uses the "tcp-common-grouping" grouping discusse d in <li>This grouping uses the "tcp-common-grouping" grouping discusse d in
<xref target="tcp-common-grouping"/>.</li> <xref target="tcp-common-grouping"/>.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Protocol-accessible Nodes</name> <name>Protocol-Accessible Nodes</name>
<t>The "ietf-tcp-client" module defines only "grouping" statements tha t are used by <t>The "ietf-tcp-client" module defines only "grouping" statements tha t are used by
other modules to instantiate protocol-accessible nodes. Thus this mod ule, when other modules to instantiate protocol-accessible nodes. Thus, this mo dule, when
implemented, does not itself define any protocol-accessible nodes.</t> implemented, does not itself define any protocol-accessible nodes.</t>
</section> </section>
</section> </section>
<section anchor="client-examples"> <section anchor="client-examples">
<name>Example Usage</name> <name>Example Usage</name>
<t>This section presents two examples showing the "tcp-client-grouping" <t>This section presents two examples showing the "tcp-client-grouping"
populated with some data. This example shows a TCP-client configured grouping
to populated with some data. This example shows a TCP client configured
not connect via a proxy:</t> to
<artwork><![CDATA[ not connect via a proxy:</t>
<sourcecode type="xml"><![CDATA[
<!-- The outermost element below doesn't exist in the data model. --> <!-- The outermost element below doesn't exist in the data model. -->
<!-- It simulates if the "grouping" were a "container" instead. --> <!-- It simulates if the "grouping" were a "container" instead. -->
<tcp-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-client"> <tcp-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-client">
<remote-address>www.example.com</remote-address> <remote-address>www.example.com</remote-address>
<remote-port>8443</remote-port> <remote-port>8443</remote-port>
<local-address>192.0.2.2</local-address> <local-address>192.0.2.2</local-address>
<local-port>12345</local-port> <local-port>12345</local-port>
<keepalives> <keepalives>
<idle-time>7200</idle-time> <idle-time>7200</idle-time>
<max-probes>9</max-probes> <max-probes>9</max-probes>
<probe-interval>75</probe-interval> <probe-interval>75</probe-interval>
</keepalives> </keepalives>
</tcp-client> </tcp-client>
]]></artwork> ]]></sourcecode>
<t>This example shows a TCP-client configured to connect via a proxy:</t <t>This example shows a TCP client configured to connect via a proxy.</t
> >
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
<!-- The outermost element below doesn't exist in the data model. --> <!-- The outermost element below doesn't exist in the data model. -->
<!-- It simulates if the "grouping" were a "container" instead. --> <!-- It simulates if the "grouping" were a "container" instead. -->
<tcp-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-client"> <tcp-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-client">
<remote-address>www.example.com</remote-address> <remote-address>www.example.com</remote-address>
<remote-port>8443</remote-port> <remote-port>8443</remote-port>
<local-address>192.0.2.2</local-address> <local-address>192.0.2.2</local-address>
<local-port>12345</local-port> <local-port>12345</local-port>
<proxy-server> <proxy-server>
<socks5-parameters> <socks5-parameters>
skipping to change at line 679 skipping to change at line 638
</username-password> </username-password>
</authentication-parameters> </authentication-parameters>
</socks5-parameters> </socks5-parameters>
</proxy-server> </proxy-server>
<keepalives> <keepalives>
<idle-time>7200</idle-time> <idle-time>7200</idle-time>
<max-probes>9</max-probes> <max-probes>9</max-probes>
<probe-interval>75</probe-interval> <probe-interval>75</probe-interval>
</keepalives> </keepalives>
</tcp-client> </tcp-client>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="client-yang-module"> <section anchor="client-yang-module">
<name>YANG Module</name> <name>YANG Module</name>
<t>The ietf-tcp-client YANG module references <xref target="SOCKS_4A"/>, <xref target="RFC1928"/>, <t>The "ietf-tcp-client" YANG module references <xref target="SOCKS"/>, <xref target="SOCKS_4A"/>, <xref target="RFC1928"/>,
<xref target="RFC1929"/>, <xref target="RFC2743"/>, <xref target="RFC699 1"/>, <xref target="RFC1929"/>, <xref target="RFC2743"/>, <xref target="RFC699 1"/>,
<xref target="RFC9293"/>, and <xref target="I-D.ietf-netconf-crypto-type <xref target="RFC9293"/>, and <xref target="RFC9640"/>.</t>
s"/>.</t> <sourcecode name="ietf-tcp-client@2024-04-04.yang" type="yang" markers="
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-tcp-client@2024-04 true"><![CDATA[
-04.yang"</t>
<artwork><![CDATA[
module ietf-tcp-client { module ietf-tcp-client {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
prefix tcpc; prefix tcpc;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"RFC AAAA: YANG Data Types and Groupings for Cryptography"; "RFC 9640: YANG Data Types and Groupings for Cryptography";
} }
import ietf-tcp-common { import ietf-tcp-common {
prefix tcpcmn; prefix tcpcmn;
reference reference
"RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; "RFC 9643: YANG Groupings for TCP Clients and TCP Servers";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group and the "IETF NETCONF (Network Configuration) Working Group and the
IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
https://datatracker.ietf.org/wg/tcpm https://datatracker.ietf.org/wg/tcpm
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
TCPM WG list <mailto:tcpm@ietf.org> TCPM WG list <mailto:tcpm@ietf.org>
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
Michael Scharf Michael Scharf
<mailto:michael.scharf@hs-esslingen.de>"; <mailto:michael.scharf@hs-esslingen.de>";
description description
"This module defines reusable groupings for TCP clients that "This module defines reusable groupings for TCP clients that
can be used as a basis for specific TCP client instances. can be used as a basis for specific TCP client instances.
Copyright (c) 2024 IETF Trust and the persons identified Copyright (c) 2024 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC DDDD This version of this YANG module is part of RFC 9643
(https://www.rfc-editor.org/info/rfcDDDD); see the RFC (https://www.rfc-editor.org/info/rfc9643); see the RFC
itself for full legal notices. itself for full legal notices.";
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2024-04-04 { revision 2024-04-04 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; "RFC 9643: YANG Groupings for TCP Clients and TCP Servers";
} }
// Features // Features
feature local-binding-supported { feature local-binding-supported {
description description
"Indicates that the server supports configuring local "Indicates that the server supports configuring local
bindings (i.e., the local address and local port) for bindings (i.e., the local address and local port) for
TCP clients."; TCP clients.";
} }
feature tcp-client-keepalives { feature tcp-client-keepalives {
description description
"Per socket TCP keepalive parameters are configurable for "TCP keepalive parameters are configurable for
TCP clients on the server implementing this feature."; TCP clients on the server implementing this feature.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP)"; "RFC 9293: Transmission Control Protocol (TCP)";
} }
feature proxy-connect { feature proxy-connect {
description description
"Indicates the TCP-client supports connecting through "Indicates the TCP client supports connecting through
TCP proxies."; TCP proxies.";
} }
feature socks4-supported { feature socks4-supported {
if-feature proxy-connect; if-feature "proxy-connect";
description description
"Indicates the TCP-client supports Socks4-based proxies."; "Indicates the TCP client supports Socks4-based proxies.";
reference reference
"SOCKS Proceedings: "SOCKS Proceedings: 1992 Usenix Security Symposium";
1992 Usenix Security Symposium.";
} }
feature socks4a-supported { feature socks4a-supported {
if-feature proxy-connect; if-feature "proxy-connect";
description description
"Indicates the TCP-client supports Socks4a-based proxies."; "Indicates the TCP client supports Socks4a-based proxies.";
reference reference
"OpenSSH message: "OpenSSH message:
SOCKS 4A: A Simple Extension to SOCKS 4 Protocol SOCKS 4A: A Simple Extension to SOCKS 4 Protocol
https://www.openssh.com/txt/socks4a.protocol."; <https://www.openssh.com/txt/socks4a.protocol>";
} }
feature socks5-supported { feature socks5-supported {
if-feature proxy-connect; if-feature "proxy-connect";
description description
"Indicates the TCP-client supports Socks5-based proxies."; "Indicates the TCP client supports Socks5-based proxies.";
reference reference
"RFC 1928: "RFC 1928: SOCKS Protocol Version 5";
SOCKS Protocol Version 5";
} }
feature socks5-gss-api { feature socks5-gss-api {
if-feature socks5-supported; if-feature "socks5-supported";
description description
"Indicates that the server, when acting as a TCP-client, "Indicates that the server, when acting as a TCP client,
supports authenticating to a SOCKS Version 5 proxy server supports authenticating to a SOCKS Version 5 proxy server
using GSSAPI credentials."; using GSS-API credentials.";
reference reference
"RFC 1928: SOCKS Protocol Version 5"; "RFC 1928: SOCKS Protocol Version 5";
} }
feature socks5-username-password { feature socks5-username-password {
if-feature socks5-supported; if-feature "socks5-supported";
description description
"Indicates that the server, when acting as a TCP-client, "Indicates that the server, when acting as a TCP client,
supports authenticating to a SOCKS Version 5 proxy server supports authenticating to a SOCKS Version 5 proxy server
using 'username' and 'password' credentials."; using 'username' and 'password' credentials.";
reference reference
"RFC 1928: SOCKS Protocol Version 5"; "RFC 1928: SOCKS Protocol Version 5";
} }
// Groupings // Groupings
grouping tcp-client-grouping { grouping tcp-client-grouping {
description description
skipping to change at line 857 skipping to change at line 806
establish a connection with. If a domain name is establish a connection with. If a domain name is
configured, then the DNS resolution should happen on configured, then the DNS resolution should happen on
each connection attempt. If the DNS resolution each connection attempt. If the DNS resolution
results in multiple IP addresses, the IP addresses results in multiple IP addresses, the IP addresses
are tried according to local preference order until are tried according to local preference order until
a connection has been established or until all IP a connection has been established or until all IP
addresses have failed."; addresses have failed.";
} }
leaf remote-port { leaf remote-port {
type inet:port-number; type inet:port-number;
default "0";
description description
"The IP port number for the remote peer to establish a "The port number of the remote TCP server.";
connection with. An invalid default value is used
so that importing modules may 'refine' it with the
appropriate default port number value.";
} }
leaf local-address { leaf local-address {
if-feature "local-binding-supported"; if-feature "local-binding-supported";
type inet:ip-address; type inet:ip-address;
description description
"The local IP address/interface to bind to for when "The local IP address/interface to bind to for when
connecting to the remote peer. INADDR_ANY ('0.0.0.0') or connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
explicitly indicate the implicit default, that the server explicitly indicate the implicit default, which the server
can bind to any IPv4 or IPv6 address."; can bind to any IPv4 or IPv6 address.";
} }
leaf local-port { leaf local-port {
if-feature "local-binding-supported"; if-feature "local-binding-supported";
type inet:port-number; type inet:port-number;
default "0"; default "0";
description description
"The local IP port number to bind to for when connecting "The local IP port number to bind to for when connecting
to the remote peer. The port number '0', which is the to the remote peer. The port number '0', which is the
default value, indicates that any available local port default value, indicates that any available local port
number may be used."; number may be used.";
} }
container proxy-server { container proxy-server {
if-feature "proxy-connect"; if-feature "proxy-connect";
presence presence "Indicates that a proxy connection has been
"Indicates that a proxy connection has been configured. configured. Present so that the mandatory
Present so that the mandatory descendant nodes do not descendant nodes do not imply that this node
imply that this node must be configured."; must be configured.";
choice proxy-type { choice proxy-type {
mandatory true; mandatory true;
description description
"Selects a proxy connection protocol."; "Selects a proxy connection protocol.";
case socks4 { case socks4 {
if-feature socks4-supported; if-feature "socks4-supported";
container socks4-parameters { container socks4-parameters {
leaf remote-address { leaf remote-address {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"The IP address of the proxy server."; "The IP address of the proxy server.";
} }
leaf remote-port { leaf remote-port {
type inet:port-number; type inet:port-number;
default "1080"; default "1080";
description description
"The IP port number for the proxy server."; "The IP port number for the proxy server.";
} }
description description
"Parameters for connecting to a TCP-based proxy "Parameters for connecting to a TCP-based proxy
server using the SOCKS4 protocol."; server using the SOCKS4 protocol.";
reference reference
"SOCKS, Proceedings: 1992 Usenix Security Symposium."; "SOCKS Proceedings: 1992 Usenix Security Symposium";
} }
} }
case socks4a { case socks4a {
if-feature socks4a-supported; if-feature "socks4a-supported";
container socks4a-parameters { container socks4a-parameters {
leaf remote-address { leaf remote-address {
type inet:host; type inet:host;
mandatory true; mandatory true;
description description
"The IP address or hostname of the proxy server."; "The IP address or hostname of the proxy server.";
} }
leaf remote-port { leaf remote-port {
type inet:port-number; type inet:port-number;
default "1080"; default "1080";
description description
"The IP port number for the proxy server."; "The IP port number for the proxy server.";
} }
description description
"Parameters for connecting to a TCP-based proxy "Parameters for connecting to a TCP-based proxy
server using the SOCKS4a protocol."; server using the SOCKS4a protocol.";
reference reference
"SOCKS Proceedings: "SOCKS Proceedings:
1992 Usenix Security Symposium. 1992 Usenix Security Symposium
OpenSSH message: OpenSSH message:
SOCKS 4A: A Simple Extension to SOCKS 4 Protocol SOCKS 4A: A Simple Extension to SOCKS 4 Protocol
https://www.openssh.com/txt/socks4a.protocol"; <https://www.openssh.com/txt/socks4a.protocol>";
} }
} }
case socks5 { case socks5 {
if-feature socks5-supported; if-feature "socks5-supported";
container socks5-parameters { container socks5-parameters {
leaf remote-address { leaf remote-address {
type inet:host; type inet:host;
mandatory true; mandatory true;
description description
"The IP address or hostname of the proxy server."; "The IP address or hostname of the proxy server.";
} }
leaf remote-port { leaf remote-port {
type inet:port-number; type inet:port-number;
default "1080"; default "1080";
description description
"The IP port number for the proxy server."; "The IP port number for the proxy server.";
} }
container authentication-parameters { container authentication-parameters {
presence presence "Indicates that an authentication mechanism
"Indicates that an authentication mechanism has been configured. Present so that the
has been configured. Present so that the mandatory descendant nodes do not imply that
mandatory descendant nodes do not imply that this node must be configured.";
this node must be configured.";
description description
"A container for SOCKS Version 5 authentication "A container for SOCKS Version 5 authentication
mechanisms. mechanisms.
A complete list of methods is defined at: A complete list of methods is defined at:
https://www.iana.org/assignments/socks-methods <https://www.iana.org/assignments/socks-methods>.";
/socks-methods.xhtml.";
reference reference
"RFC 1928: SOCKS Protocol Version 5"; "RFC 1928: SOCKS Protocol Version 5";
choice auth-type { choice auth-type {
mandatory true; mandatory true;
description description
"A choice amongst supported SOCKS Version 5 "A choice amongst supported SOCKS Version 5
authentication mechanisms."; authentication mechanisms.";
case gss-api { case gss-api {
if-feature "socks5-gss-api"; if-feature "socks5-gss-api";
container gss-api { container gss-api {
skipping to change at line 1008 skipping to change at line 951
description description
"The 'username' value to use for client "The 'username' value to use for client
identification."; identification.";
} }
uses ct:password-grouping { uses ct:password-grouping {
description description
"The password to be used for client "The password to be used for client
authentication."; authentication.";
} }
description description
"Contains Username/Password configuration."; "Contains username/password configuration.";
reference reference
"RFC 1929: Username/Password Authentication "RFC 1929: Username/Password Authentication
for SOCKS V5"; for SOCKS V5";
} }
} }
} }
} }
description description
"Parameters for connecting to a TCP-based proxy server "Parameters for connecting to a TCP-based proxy server
using the SOCKS5 protocol."; using the SOCKS5 protocol.";
skipping to change at line 1032 skipping to change at line 975
} }
} }
description description
"Proxy server settings."; "Proxy server settings.";
} }
uses tcpcmn:tcp-common-grouping { uses tcpcmn:tcp-common-grouping {
refine "keepalives" { refine "keepalives" {
if-feature "tcp-client-keepalives"; if-feature "tcp-client-keepalives";
description description
"An if-feature statement so that implementations "An 'if-feature' statement so that implementations
can choose to support TCP client keepalives."; can choose to support TCP client keepalives.";
} }
} }
} }
} }
]]></artwork> ]]></sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
</section> </section>
<section anchor="tcp-server-model"> <section anchor="tcp-server-model">
<name>The "ietf-tcp-server" Module</name> <name>The "ietf-tcp-server" Module</name>
<t>This section defines a YANG 1.1 module called <t>This section defines a YANG 1.1 module called
"ietf-tcp-server". A high-level overview of the module is provided in "ietf-tcp-server". A high-level overview of the module is provided in
<xref target="server-overview"/>. Examples illustrating the module's use <xref target="server-overview"/>. Examples illustrating the module's use
are provided in <xref target="server-examples">Examples</xref>. The YANG are provided in <xref target="server-examples"/> ("Example Usage"). The YANG
module itself is defined in <xref target="server-yang-module"/>.</t> module itself is defined in <xref target="server-yang-module"/>.</t>
<section anchor="server-overview"> <section anchor="server-overview">
<name>Data Model Overview</name> <name>Data Model Overview</name>
<t>This section provides an overview of the "ietf-tcp-server" module <t>This section provides an overview of the "ietf-tcp-server" module
in terms of its features and groupings.</t> in terms of its features and groupings.</t>
<section toc="exclude"> <section toc="exclude">
<name>Features</name> <name>Features</name>
<t>The following diagram lists all the "feature" statements <t>The following diagram lists all the "feature" statements
defined in the "ietf-tcp-server" module:</t> defined in the "ietf-tcp-server" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Features: Features:
+-- tcp-server-keepalives +-- tcp-server-keepalives
]]></artwork> ]]></sourcecode>
<!--<aside>--> <!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340"/>.</t>
<!--</aside>--> <!--</aside>-->
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Groupings</name> <name>Groupings</name>
<t>The "ietf-tcp-server" module defines the following "grouping" state ment:</t> <t>The "ietf-tcp-server" module defines the following "grouping" state ment:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>tcp-server-grouping</li> <li>tcp-server-grouping</li>
</ul> </ul>
<t>This grouping is presented in the following subsection.</t> <t>This grouping is presented in the following subsection.</t>
<section anchor="tcp-server-grouping"> <section anchor="tcp-server-grouping">
<name>The "tcp-server-grouping" Grouping</name> <name>The "tcp-server-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"tcp-server-grouping" grouping:</t> "tcp-server-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping tcp-server-grouping: grouping tcp-server-grouping:
+-- local-bind* [local-address] +-- local-bind* [local-address]
| +-- local-address? inet:ip-address | +-- local-address inet:ip-address
| +-- local-port? inet:port-number | +-- local-port? inet:port-number
+---u tcpcmn:tcp-common-grouping +---u tcpcmn:tcp-common-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "local-address" node, which is mandatory, may be configure d as <li>The "local-address" node, which is mandatory, may be configure d as
an IPv4 address, an IPv6 address, or a wildcard value.</li> an IPv4 address, an IPv6 address, or a wildcard value.</li>
<li>The "local-port" node is not mandatory, but its default value <li>The "local-port" leaf is defined with neither a "default" nor
is a "mandatory"
the invalid value '0', thus forcing the consuming data model to statement. YANG modules using this grouping <bcp14>SHOULD</bcp14> refine the
refine it in order to provide it an appropriate default value.</ grouping with a "default" statement, when the port number is well-known (e.g., a
li> port number allocated by IANA), or with a "mandatory" statement, if a port
number needs to always be configured. The <bcp14>SHOULD</bcp14> can be ignore
d when the port number is neither well-known nor mandatory to configure, such as
might be the case when this grouping is used by another grouping.</li>
<li>This grouping uses the "tcp-common-grouping" grouping discusse d in <li>This grouping uses the "tcp-common-grouping" grouping discusse d in
<xref target="tcp-common-grouping"/>.</li> <xref target="tcp-common-grouping"/>.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Protocol-accessible Nodes</name> <name>Protocol-Accessible Nodes</name>
<t>The "ietf-tcp-server" module defines only "grouping" statements tha t are used by <t>The "ietf-tcp-server" module defines only "grouping" statements tha t are used by
other modules to instantiate protocol-accessible nodes. Thus this m odule, when other modules to instantiate protocol-accessible nodes. Thus, this module, when
implemented, does not itself define any protocol-accessible nodes.</ t> implemented, does not itself define any protocol-accessible nodes.</ t>
</section> </section>
</section> </section>
<section anchor="server-examples"> <section anchor="server-examples">
<name>Example Usage</name> <name>Example Usage</name>
<t>This section presents an example showing the "tcp-server-grouping" <t>This section presents an example showing the "tcp-server-grouping" gr ouping
populated with some data.</t> populated with some data.</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
<!-- The outermost element below doesn't exist in the data model. --> <!-- The outermost element below doesn't exist in the data model. -->
<!-- It simulates if the "grouping" were a "container" instead. --> <!-- It simulates if the "grouping" were a "container" instead. -->
<tcp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-server"> <tcp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-server">
<local-bind> <local-bind>
<local-address>192.0.2.2</local-address> <local-address>192.0.2.2</local-address>
<local-port>49152</local-port> <local-port>49152</local-port>
</local-bind> </local-bind>
<keepalives> <keepalives>
<idle-time>7200</idle-time> <idle-time>7200</idle-time>
<max-probes>9</max-probes> <max-probes>9</max-probes>
<probe-interval>75</probe-interval> <probe-interval>75</probe-interval>
</keepalives> </keepalives>
</tcp-server> </tcp-server>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="server-yang-module"> <section anchor="server-yang-module">
<name>YANG Module</name> <name>YANG Module</name>
<t>The ietf-tcp-server YANG module references <xref target="RFC6991"/> <t>The "ietf-tcp-server" YANG module references <xref target="RFC6991"/>
and <xref target="RFC9293"/>.</t> and <xref target="RFC9293"/>.</t>
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-tcp-server@2024-04 <sourcecode name="ietf-tcp-server@2024-04-04.yang" type="yang" markers="
-04.yang"</t> true"><![CDATA[
<artwork><![CDATA[
module ietf-tcp-server { module ietf-tcp-server {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
prefix tcps; prefix tcps;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-tcp-common { import ietf-tcp-common {
prefix tcpcmn; prefix tcpcmn;
reference reference
"RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; "RFC 9643: YANG Groupings for TCP Clients and TCP Servers";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group and the "IETF NETCONF (Network Configuration) Working Group and the
IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
https://datatracker.ietf.org/wg/tcpm https://datatracker.ietf.org/wg/tcpm
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
TCPM WG list <mailto:tcpm@ietf.org> TCPM WG list <mailto:tcpm@ietf.org>
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
Michael Scharf Michael Scharf
<mailto:michael.scharf@hs-esslingen.de>"; <mailto:michael.scharf@hs-esslingen.de>";
description description
"This module defines reusable groupings for TCP servers that "This module defines reusable groupings for TCP servers that
can be used as a basis for specific TCP server instances. can be used as a basis for specific TCP server instances.
Copyright (c) 2024 IETF Trust and the persons identified Copyright (c) 2024 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC DDDD This version of this YANG module is part of RFC 9643
(https://www.rfc-editor.org/info/rfcDDDD); see the RFC (https://www.rfc-editor.org/info/rfc9643); see the RFC
itself for full legal notices. itself for full legal notices.";
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2024-04-04 { revision 2024-04-04 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; "RFC 9643: YANG Groupings for TCP Clients and TCP Servers";
} }
// Features // Features
feature tcp-server-keepalives { feature tcp-server-keepalives {
description description
"Per socket TCP keepalive parameters are configurable for "TCP keepalive parameters are configurable for
TCP servers on the server implementing this feature."; TCP servers on the server implementing this feature.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP)"; "RFC 9293: Transmission Control Protocol (TCP)";
} }
// Groupings // Groupings
grouping tcp-server-grouping { grouping tcp-server-grouping {
description description
"A reusable grouping for configuring a TCP server. "A reusable grouping for configuring a TCP server.
Note that this grouping uses fairly typical descendant Note that this grouping uses fairly typical descendant
node names such that a stack of 'uses' statements will node names such that a stack of 'uses' statements will
have name conflicts. It is intended that the consuming have name conflicts. It is intended that the consuming
data model will resolve the issue (e.g., by wrapping data model will resolve the issue (e.g., by wrapping
the 'uses' statement in a container called the 'uses' statement in a container called
'tcp-server-parameters'). This model purposely does 'tcp-server-parameters'). This model purposely does
not do this itself so as to provide maximum flexibility not do this itself so as to provide maximum flexibility
to consuming models."; to consuming models.";
list local-bind { list local-bind {
key local-address; key "local-address";
min-elements 1; min-elements 1;
description description
"A list of bind (listen) points for this server "A list of bind (listen) points for this server
instance. A server instance may have multiple instance. A server instance may have multiple
bind points to support, e.g., the same port in bind points to support, e.g., the same port in
different address families or different ports different address families or different ports
in the same address family."; in the same address family.";
leaf local-address { leaf local-address {
type inet:ip-address; type inet:ip-address;
description description
"The local IP address to listen on for incoming "The local IP address to listen on for incoming
TCP client connections. To configure listening TCP client connections. To configure listening
on all IPv4 addresses the value must be '0.0.0.0' on all IPv4 addresses, the value must be '0.0.0.0'
(INADDR_ANY). To configure listening on all IPv6 (INADDR_ANY). To configure listening on all IPv6
addresses the value must be '::' (INADDR6_ANY)."; addresses, the value must be '::' (INADDR6_ANY).";
} }
leaf local-port { leaf local-port {
type inet:port-number; type inet:port-number;
default "0";
description description
"The local port number to listen on for incoming TCP "The local port number to listen on for incoming TCP
client connections. An invalid default value (0) client connections.”;
is used (instead of 'mandatory true') so that an
application level data model may 'refine' it with
an application specific default port number value.";
} }
} }
uses tcpcmn:tcp-common-grouping { uses tcpcmn:tcp-common-grouping {
refine "keepalives" { refine "keepalives" {
if-feature "tcp-server-keepalives"; if-feature "tcp-server-keepalives";
description description
"An if-feature statement so that implementations "An 'if-feature' statement so that implementations
can choose to support TCP server keepalives."; can choose to support TCP server keepalives.";
} }
} }
} }
} }
]]></artwork> ]]></sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
</section> </section>
<section> <section>
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The three YANG modules in this document define groupings and will <t>The three YANG modules in this document define groupings and will
not be deployed as standalone modules. Their security implications not be deployed as standalone modules. Their security implications
may be context dependent based on their use in other modules. The may be context-dependent based on their use in other modules. The
designers of modules which import these grouping must conduct their designers of modules that import these groupings must conduct their
own analysis of the security considerations.</t> own analysis of the security considerations.</t>
<section> <section>
<!--[rfced] *AD - We note that the text in Sections 5.1-5.3 do not exactly
match the YANG security considerations boilerplate text at
<https://wiki.ietf.org/group/ops/yang-security-guidelines>, including
missing citations to RFCs 6242 and 8446. Please review and let us know if
the text requires any updates.
-->
<name>Considerations for the "ietf-tcp-common" YANG Module</name> <name>Considerations for the "ietf-tcp-common" YANG Module</name>
<t>This section follows the template defined in <xref section="3.7.1" ta rget="RFC8407"/>.</t> <t>This section is modeled after the template defined in <xref section=" 3.7.1" sectionFormat="of" target="RFC8407"/>.</t>
<t>The "ietf-tcp-common" YANG module defines "grouping" statements <t>The "ietf-tcp-common" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management that are designed to be accessed via YANG-based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have <xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS) mandatory-to-implement secure transport layers (e.g.,
with mutual authentication.</t> Secure Shell (SSH) <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, an
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> d QUIC <xref target="RFC9000"/>) and
mandatory-to-implement mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="R
FC8341"/>
provides the means to restrict access for particular users to a provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and preconfigured subset of all available protocol operations and
content.</t> content.</t>
<t>Please be aware that this YANG module uses groupings from <t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules review the security considerations for dependent YANG modules
for information as to which nodes may be considered sensitive for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t> or vulnerable in network environments.</t>
<t>None of the readable data nodes defined in this YANG module are <t>None of the readable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments. considered sensitive or vulnerable in network environments.
The NACM "default-deny-all" extension has not been set for The NACM "default-deny-all" extension has not been set for
any data nodes defined in this module.</t> any data nodes defined in this module.</t>
<t>None of the writable data nodes defined in this YANG module are <t>None of the writable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments. considered sensitive or vulnerable in network environments.
The NACM "default-deny-write" extension has not been set for The NACM "default-deny-write" extension has not been set for
any data nodes defined in this module.</t> any data nodes defined in this module.</t>
<t>This module does not define any RPCs, actions, or notifications, <t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t> and thus, the security considerations for such are not provided here.< /t>
</section> </section>
<section> <section>
<name>Considerations for the "ietf-tcp-client" YANG Module</name> <name>Considerations for the "ietf-tcp-client" YANG Module</name>
<t>This section follows the template defined in <xref section="3.7.1" ta rget="RFC8407"/>.</t> <t>This section is modeled after the template defined in <xref section=" 3.7.1" sectionFormat="of" target="RFC8407"/>.</t>
<t>The "ietf-tcp-client" YANG module defines "grouping" statements <t>The "ietf-tcp-client" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management that are designed to be accessed via YANG-based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have <xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS) mandatory-to-implement secure transport layers (e.g.,
with mutual authentication.</t> Secure Shell (SSH) <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, an
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> d QUIC <xref target="RFC9000"/>) and
mandatory-to-implement mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="R
FC8341"/>
provides the means to restrict access for particular users to a provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and preconfigured subset of all available protocol operations and
content.</t> content.</t>
<t>Please be aware that this YANG module uses groupings from <t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules review the security considerations for dependent YANG modules
for information as to which nodes may be considered sensitive for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t> or vulnerable in network environments.</t>
<t>One readable data node defined in this YANG module may be considered <t>One readable data node defined in this YANG module may be considered
sensitive or vulnerable in some network environments. This sensitive or vulnerable in some network environments. This
node is as follows: node is as follows:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The "proxy-server/socks5-parameters/authentication-parameters/use rname-password/password" node: <t>The "proxy-server/socks5-parameters/authentication-parameters/use rname-password/password" node:
</t> </t>
<ul empty="true"> <ul empty="true">
<li>The "password" node defined in the "tcp-client-grouping" <li>The "password" node defined in the "tcp-client-grouping"
grouping is defined using the "password-grouping" grouping grouping is defined using the "password-grouping" grouping
presented in <xref target="I-D.ietf-netconf-crypto-types"/>. presented in <xref target="RFC9640"/>.
This grouping enables both cleartext and encrypted passwords This grouping enables both cleartext and encrypted passwords
to be configured. As the referenced document states, configur ation to be configured. As the referenced document states, configur ation
of cleartext passwords is NOT RECOMMENDED. However, in the of cleartext passwords is <bcp14>NOT RECOMMENDED</bcp14>. How ever, in the
case cleartext values are configured, this node is additionall y case cleartext values are configured, this node is additionall y
sensitive to read operations such that, in normal use cases, sensitive to read operations such that, in normal use cases,
it should never be returned to a client. For this reason, the it should never be returned to a client. For this reason, the
NACM extension "default-deny-all" has been applied to it.</li> NACM "default-deny-all" extension has been applied to it.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>None of the writable data nodes defined in this YANG module are <t>None of the writable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments. considered sensitive or vulnerable in network environments.
The NACM "default-deny-write" extension has not been set for The NACM "default-deny-write" extension has not been set for
any data nodes defined in this module.</t> any data nodes defined in this module.</t>
<t>This module does not define any RPCs, actions, or notifications, <t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t> and thus, the security considerations for such are not provided here.<
<t>Implementations are RECOMMENDED to implement the "local-binding-suppo /t>
rted" <t>Implementations are <bcp14>RECOMMENDED</bcp14> to implement the "loca
feature for cryptographically-secure protocols, so as to enable more l-binding-supported"
granular ingress/egress firewall rulebases. It is NOT RECOMMENDED to feature for cryptographically secure protocols so as to enable more
granular ingress/egress firewall rule bases. It is <bcp14>NOT RECOMME
NDED</bcp14> to
implement this feature for unsecure protocols, as per <xref target="RF C6056"/>.</t> implement this feature for unsecure protocols, as per <xref target="RF C6056"/>.</t>
</section> </section>
<section> <section>
<name>Considerations for the "ietf-tcp-server" YANG Module</name> <name>Considerations for the "ietf-tcp-server" YANG Module</name>
<t>This section follows the template defined in <xref section="3.7.1" ta rget="RFC8407"/>.</t> <t>This section is modeled after the template defined in <xref section=" 3.7.1" sectionFormat="of" target="RFC8407"/>.</t>
<t>The "ietf-tcp-server" YANG module defines "grouping" statements <t>The "ietf-tcp-server" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management that are designed to be accessed via YANG-based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have <xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS) mandatory-to-implement secure transport layers (e.g.,
with mutual authentication.</t> Secure Shell (SSH) <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, an
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> d QUIC <xref target="RFC9000"/>) and
mandatory-to-implement mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="R
FC8341"/>
provides the means to restrict access for particular users to a provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and preconfigured subset of all available protocol operations and
content.</t> content.</t>
<t>Please be aware that this YANG module uses groupings from <t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules review the security considerations for dependent YANG modules
for information as to which nodes may be considered sensitive for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t> or vulnerable in network environments.</t>
<t>None of the readable data nodes defined in this YANG module are <t>None of the readable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments. considered sensitive or vulnerable in network environments.
The NACM "default-deny-all" extension has not been set for The NACM "default-deny-all" extension has not been set for
any data nodes defined in this module.</t> any data nodes defined in this module.</t>
<t>None of the writable data nodes defined in this YANG module are <t>None of the writable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments. considered sensitive or vulnerable in network environments.
The NACM "default-deny-write" extension has not been set for The NACM "default-deny-write" extension has not been set for
any data nodes defined in this module.</t> any data nodes defined in this module.</t>
<t>This module does not define any RPCs, actions, or notifications, <t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t> and thus, the security considerations for such are not provided here.< /t>
</section> </section>
</section> </section>
<section> <section>
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section> <section>
<name>The "IETF XML" Registry</name> <name>The IETF XML Registry</name>
<t>This document registers three URIs in the "ns" subregistry of the <t>IANA has registered the following URI in the "ns" registry of
IETF XML Registry <xref target="RFC3688"/>. Following the format in the "IETF XML Registry" <xref target="RFC3688"/>.</t>
<xref target="RFC3688"/>, the following registrations are <!-- note for IANA:
requested:</t> Please update comma to semicolon here.
<artwork><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client OLD: N/A, the requested URI is an XML namespace.
Registrant Contact: The IESG NEW: N/A; the requested URI is an XML namespace.
XML: N/A, the requested URI is an XML namespace. -->
<dl newline="false" spacing="compact">
<dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-tcp-common</dd>
<dt>Registrant Contact:</dt> <dd>The IESG</dd>
<dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server <dl newline="false" spacing="compact">
Registrant Contact: The IESG <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-tcp-client</dd>
XML: N/A, the requested URI is an XML namespace. <dt>Registrant Contact:</dt> <dd>The IESG</dd>
]]></artwork> <dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-tcp-server</dd>
<dt>Registrant Contact:</dt> <dd>The IESG</dd>
<dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
</section> </section>
<section> <section>
<name>The "YANG Module Names" Registry</name> <name>The YANG Module Names Registry</name>
<t>This document registers three YANG modules in the YANG Module Names <t>IANA has registered the following three YANG modules in the "YANG Mod
registry <xref target="RFC6020"/>. Following the format in <xref target= ule Names"
"RFC6020"/>, the following registrations are requested:</t> registry <xref target="RFC6020"/>. </t>
<artwork><![CDATA[ <dl newline="false" spacing="compact">
name: ietf-tcp-common <dt>Name:</dt> <dd>ietf-tcp-common</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-tcp-common</dd>
prefix: tcpcmn <dt>Prefix:</dt> <dd>tcpcmn</dd>
reference: RFC DDDD <dt>Reference:</dt> <dd>RFC 9643</dd>
</dl>
name: ietf-tcp-client <dl newline="false" spacing="compact">
namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client <dt>Name:</dt> <dd>ietf-tcp-client</dd>
prefix: tcpc <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-tcp-client</dd>
reference: RFC DDDD <dt>Prefix:</dt> <dd>tcpc</dd>
<dt>Reference:</dt> <dd>RFC 9643</dd>
name: ietf-tcp-server </dl>
namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server <dl newline="false" spacing="compact">
prefix: tcps <dt>Name:</dt> <dd>ietf-tcp-server</dd>
reference: RFC DDDD <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-tcp-server</dd>
]]></artwork> <dt>Prefix:</dt> <dd>tcps</dd>
<dt>Reference:</dt> <dd>RFC 9643</dd>
</dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-netconf-http-client-server"
to="HTTP-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netconf-netconf-client-server"
to="NETCONF-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netconf-restconf-client-server"
to="RESTCONF-CLIENT-SERVER"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
le> 52.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
<date month="March" year="1997"/> 20.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
<t>In many standards track documents several words are used to sig 91.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
his document defines these words as they should be interpreted in IETF documents 50.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
mmunity, and requests discussion and suggestions for improvements.</t> 74.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
</front> 41.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
<seriesInfo name="RFC" value="2119"/> 00.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
</reference> 93.xml"/>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"> <!-- [I-D.ietf-netconf-crypto-types] companion document RFC 9640 -->
<front>
<title>YANG - A Data Modeling Language for the Network Configuration <reference anchor="RFC9640" target="https://www.rfc-editor.org/info/rfc96
Protocol (NETCONF)</title> 40">
<author fullname="M. Bjorklund" initials="M." role="editor" surname= <front>
"Bjorklund"/> <title>YANG Data Types and Groupings for Cryptography</title>
<date month="October" year="2010"/> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<abstract> <organization>Watsen Networks</organization>
<t>YANG is a data modeling language used to model configuration an </author>
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON <date month="September" year="2024"/>
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> </front>
</abstract> <seriesInfo name="RFC" value="9640"/>
</front> <seriesInfo name="DOI" value="10.17487/RFC9640"/>
<seriesInfo name="RFC" value="6020"/> </reference>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6
991" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml">
<front>
<title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<date month="July" year="2013"/>
<abstract>
<t>This document introduces a collection of common data types to b
e used with the YANG data modeling language. This document obsoletes RFC 6021.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<date month="August" year="2016"/>
<abstract>
<t>YANG is a data modeling language used to model configuration da
ta, state data, Remote Procedure Calls, and notifications for network management
protocols. This document describes the syntax and semantics of version 1.1 of t
he YANG language. YANG version 1.1 is a maintenance release of the YANG language
, addressing ambiguities and defects in the original specification. There are a
small number of backward incompatibilities from YANG version 1. This document al
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8
341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
ires a structured and secure operating environment that promotes human usability
and multi-vendor interoperability. There is a need for standard mechanisms to r
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
red subset of all available NETCONF or RESTCONF protocol operations and content.
This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<reference anchor="RFC9293" target="https://www.rfc-editor.org/info/rfc9
293" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml">
<front>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
"/>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack, a
nd it has continuously evolved over decades of use and growth of the Internet. O
ver this time, a number of changes have been made to TCP as it was specified in
RFC 793, though these have only been documented in a piecemeal fashion. This doc
ument collects and brings those changes together with the protocol specification
from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-crypto-types.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC1928" target="https://www.rfc-editor.org/info/rfc1
928" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.19
<front> 28.xml"/>
<title>SOCKS Protocol Version 5</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.19
<author fullname="M. Leech" initials="M." surname="Leech"/> 29.xml"/>
<author fullname="M. Ganis" initials="M." surname="Ganis"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.27
<author fullname="Y. Lee" initials="Y." surname="Lee"/> 43.xml"/>
<author fullname="R. Kuris" initials="R." surname="Kuris"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36
<author fullname="D. Koblas" initials="D." surname="Koblas"/> 88.xml"/>
<author fullname="L. Jones" initials="L." surname="Jones"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
<date month="March" year="1996"/> 56.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
<t>This memo describes a protocol that is an evolution of the prev 41.xml"/>
ious version of the protocol, version 4 [1]. This new protocol stems from active <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
discussions and prototype implementations. [STANDARDS-TRACK]</t> 40.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
</front> 59.xml"/>
<seriesInfo name="RFC" value="1928"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<seriesInfo name="DOI" value="10.17487/RFC1928"/> 40.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<reference anchor="RFC1929" target="https://www.rfc-editor.org/info/rfc1 42.xml"/>
929" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1929.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<front> 07.xml"/>
<title>Username/Password Authentication for SOCKS V5</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<author fullname="M. Leech" initials="M." surname="Leech"/> 46.xml"/>
<date month="March" year="1996"/>
<abstract> <!-- [I-D.ietf-netconf-trust-anchors] companion document RFC 9641 -->
<t>The protocol specification for SOCKS Version 5 specifies a gene <reference anchor="RFC9641" target="https://www.rfc-editor.org/info/rfc96
ralized framework for the use of arbitrary authentication protocols in the initi 41">
al socks connection setup. This document describes one of those protocols, as it <front>
fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK <title>A YANG Data Model for a Truststore</title>
]</t> <author initials="K." surname="Watsen" fullname="Kent Watsen">
</abstract> <organization>Watsen Networks</organization>
</front> </author>
<seriesInfo name="RFC" value="1929"/> <date month="September" year="2024"/>
<seriesInfo name="DOI" value="10.17487/RFC1929"/> </front>
</reference> <seriesInfo name="RFC" value="9641"/>
<reference anchor="RFC2743" target="https://www.rfc-editor.org/info/rfc2 <seriesInfo name="DOI" value="10.17487/RFC9641"/>
743" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2743.xml"> </reference>
<front>
<title>Generic Security Service Application Program Interface Versio <!-- [I-D.ietf-netconf-keystore] companion document RFC 9642 -->
n 2, Update 1</title> <reference anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc96
<author fullname="J. Linn" initials="J." surname="Linn"/> 42">
<date month="January" year="2000"/> <front>
<abstract> <title>A YANG Data Model for a Keystore</title>
<t>This memo obsoletes [STANDARDS-TRACK]</t> <author initials="K." surname="Watsen" fullname="Kent Watsen">
</abstract> <organization>Watsen Networks</organization>
</front> </author>
<seriesInfo name="RFC" value="2743"/> <date month="September" year="2024"/>
<seriesInfo name="DOI" value="10.17487/RFC2743"/> </front>
</reference> <seriesInfo name="RFC" value="9642"/>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3 <seriesInfo name="DOI" value="10.17487/RFC9642"/>
688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> </reference>
<front>
<title>The IETF XML Registry</title> <!-- [I-D.ietf-netconf-ssh-client-server] companion document RFC 9644 -->
<author fullname="M. Mealling" initials="M." surname="Mealling"/> <reference anchor="RFC9644" target="https://www.rfc-editor.org/info/rfc96
<date month="January" year="2004"/> 44">
<abstract> <front>
<t>This document describes an IANA maintained registry for IETF st <title>YANG Groupings for SSH Clients and SSH Servers</title>
andards which use Extensible Markup Language (XML) related items such as Namespa <author initials="K." surname="Watsen" fullname="Kent Watsen">
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew <organization>Watsen Networks</organization>
ork (RDF) Schemas.</t> </author>
</abstract> <date month="September" year="2024"/>
</front> </front>
<seriesInfo name="BCP" value="81"/> <seriesInfo name="RFC" value="9644"/>
<seriesInfo name="RFC" value="3688"/> <seriesInfo name="DOI" value="10.17487/RFC9644"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/> </reference>
</reference>
<reference anchor="RFC6056" target="https://www.rfc-editor.org/info/rfc6 <!-- [I-D.ietf-netconf-tls-client-server] companion document RFC 9645 -->
056" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6056.xml"> <reference anchor="RFC9645" target="https://www.rfc-editor.org/info/rfc96
<front> 45">
<title>Recommendations for Transport-Protocol Port Randomization</ti <front>
tle> <title>YANG Groupings for TLS Clients and TLS Servers</title>
<author fullname="M. Larsen" initials="M." surname="Larsen"/> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<author fullname="F. Gont" initials="F." surname="Gont"/> <organization>Watsen Networks</organization>
<date month="January" year="2011"/> </author>
<abstract> <date month="September" year="2024"/>
<t>During the last few years, awareness has been raised about a nu </front>
mber of "blind" attacks that can be performed against the Transmission Control P <seriesInfo name="RFC" value="9645"/>
rotocol (TCP) and similar protocols. The consequences of these attacks range fro <seriesInfo name="DOI" value="10.17487/RFC9645"/>
m throughput reduction to broken connections or data corruption. These attacks r </reference>
ely on the attacker's ability to guess or know the five-tuple (Protocol, Source
Address, Destination Address, Source Port, Destination Port) that identifies the <!-- [I-D.ietf-netconf-http-client-server] IESG state: IESG Evaluation::AD Follo
transport protocol instance to be attacked. This document describes a number of wup -->
simple and efficient methods for the selection of the client port number, such <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
that the possibility of an attacker guessing the exact value is reduced. While t conf-http-client-server"/>
his is not a replacement for cryptographic methods for protecting the transport-
protocol instance, the aforementioned port selection algorithms provide improved <!-- [I-D.ietf-netconf-netconf-client-server] IESG state: AD Evaluation -->
security with very little effort and without any key management overhead. The a <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
lgorithms described in this document are local policies that may be incrementall conf-netconf-client-server"/>
y deployed and that do not violate the specifications of any of the transport pr
otocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control T <!-- [I-D.ietf-netconf-restconf-client-server] IESG state: AD Evaluation-->
ransmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RT <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
P (provided that the RTP application explicitly signals the RTP and RTCP port nu conf-restconf-client-server"/>
mbers). This memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="156"/>
<seriesInfo name="RFC" value="6056"/>
<seriesInfo name="DOI" value="10.17487/RFC6056"/>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns
"/>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman"/>
<date month="June" year="2011"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this do
cument provides mechanisms to install, manipulate, and delete the configuration
of network devices. It uses an Extensible Markup Language (XML)-based data encod
ing for the configuration data as well as the protocol messages. The NETCONF pro
tocol operations are realized as remote procedure calls (RPCs). This document ob
soletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<date month="January" year="2017"/>
<abstract>
<t>This document describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the datastore c
oncepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
<front>
<title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be
rger"/>
<date month="March" year="2018"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree diagrams. The purpose of this document is to provide a single location for t
his definition. This syntax may be updated from time to time based on the evolut
ion of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
lder"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/>
<date month="March" year="2018"/>
<abstract>
<t>Datastores are a fundamental concept binding the data models wr
itten in the YANG data modeling language to network management protocols such as
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define
s an architectural framework for datastores based on the experience gained with
the initial simpler model, addressing requirements that were not well supported
in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8
407" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<date month="October" year="2018"/>
<abstract>
<t>This memo provides guidelines for authors and reviewers of spec
ifications containing YANG modules. Recommendations and procedures are defined,
which are intended to increase interoperability and usability of Network Configu
ration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YAN
G modules. This document obsoletes RFC 6087.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="216"/>
<seriesInfo name="RFC" value="8407"/>
<seriesInfo name="DOI" value="10.17487/RFC8407"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-trust-anchors.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-keystore.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-tcp-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-ssh-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-tls-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-http-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-netconf-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-restconf-client-server.xml"/>
<reference anchor="SOCKS_4A" target="https://www.openssh.com/txt/socks4a .protocol"> <reference anchor="SOCKS_4A" target="https://www.openssh.com/txt/socks4a .protocol">
<front> <front>
<title>SOCKS 4A: A Simple Extension to SOCKS 4 Protocol</title> <title>SOCKS 4A: A Simple Extension to SOCKS 4 Protocol</title>
<author fullname="The OpenSSH Project"/> <author fullname="Ying-Da Lee" surname="Lee" initials="Y."/>
</front> </front>
</reference> </reference>
<reference anchor="SOCKS" target="https://www.usenix.org/legacy/publicati
ons/library/proceedings/sec92/full_papers/koblas.pdf">
<front>
<title>SOCKS</title>
<author fullname="David Koblas" surname="Koblas" initials="D."/>
<author fullname="Michelle R. Koblas" surname="Koblas" initials="M."/
>
<date month="September" year="1992"/>
</front>
<refcontent>USENIX UNIX Security Symposium III</refcontent>
</reference>
<reference anchor="W3C.REC-xml-20081126"
target="https://www.w3.org/TR/2008/REC-xml-20081126/">
<front>
<title>Extensible Markup Language (XML) 1.0
(Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"/>
<author initials="J." surname="Paoli" fullname="Jean Paoli"/>
<author initials="C.M." surname="Sperberg-McQueen" fullname="C. M.
Sperberg-McQueen"/>
<author initials="E." surname="Maler" fullname="Eve Maler"/>
<author initials="F." surname="Yergeau" fullname="François Yergeau"/>
<date month="November" year="2008"/>
</front>
<seriesInfo name="World Wide Web Consortium
Recommendation" value="REC-xml-20081126"/>
</reference>
</references> </references>
</references> </references>
<section anchor="change-log">
<name>Change Log</name>
<section>
<name>00 to 01</name>
<ul spacing="normal">
<li>Added 'local-binding-supported' feature to TCP-client model.</li>
<li>Added 'keepalives-supported' feature to TCP-common model.</li>
<li>Added 'external-endpoint-values' container and 'external-endpoints
' feature to TCP-server model.</li>
</ul>
</section>
<section>
<name>01 to 02</name>
<ul spacing="normal">
<li>Removed the 'external-endpoint-values' container and 'external-end
points' feature from the TCP-server model.</li>
</ul>
</section>
<section>
<name>02 to 03</name>
<ul spacing="normal">
<li>Moved the common model section to be before the client and server
specific sections.</li>
<li>Added sections "Model Scope" and "Usage Guidelines for Configuring
TCP Keep-Alives" to
the common model section.</li>
</ul>
</section>
<section>
<name>03 to 04</name>
<ul spacing="normal">
<li>Fixed a few typos.</li>
</ul>
</section>
<section>
<name>04 to 05</name>
<ul spacing="normal">
<li>Removed commented out "grouping tcp-system-grouping" statement kep
t for reviewers.</li>
<li>Added a "Note to Reviewers" note to first page.</li>
</ul>
</section>
<section>
<name>05 to 06</name>
<ul spacing="normal">
<li>Added support for TCP proxies.</li>
</ul>
</section>
<section>
<name>06 to 07</name>
<ul spacing="normal">
<li>Expanded "Data Model Overview section(s) [remove "wall" of tree di
agrams].</li>
<li>Updated the Security Considerations section.</li>
</ul>
</section>
<section>
<name>07 to 08</name>
<ul spacing="normal">
<li>Added missing IANA registration for "ietf-tcp-common"</li>
<li>Added "mandatory true" for the "username" and "password" leafs</li
>
<li>Added an example of a TCP-client configured to connect via a proxy
</li>
<li>Fixed issues found by the SecDir review of the "keystore" draft.</
li>
<li>Updated the "ietf-tcp-client" module to use the new "password-grou
ping"
grouping from the "crypto-types" module.</li>
</ul>
</section>
<section>
<name>08 to 09</name>
<ul spacing="normal">
<li>Addressed comments raised by YANG Doctor in the ct/ts/ks drafts.</
li>
</ul>
</section>
<section>
<name>09 to 10</name>
<ul spacing="normal">
<li>Updated Abstract and Intro to address comments by Tom Petch.</li>
<li>Removed the "tcp-connection-grouping" grouping (now models use the
"tcp-common-grouping" directly).</li>
<li>Added XML-comment above examples explaining the reason for the unu
sual top-most element's presence.</li>
<li>Added Securty Considerations section for the "local-binding-suppor
ted" feature.</li>
<li>Replaced some hardcoded refs to &lt;xref&gt; elements.</li>
<li>Fixed nits found by YANG Doctor reviews.</li>
<li>Aligned modules with `pyang -f` formatting.</li>
<li>Added an "Acknowledgements" secetion.</li>
</ul>
</section>
<section>
<name>10 to 11</name>
<ul spacing="normal">
<li>Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.</
li>
<li>Minor editorial nits</li>
</ul>
</section>
<section>
<name>11 to 12</name>
<ul spacing="normal">
<li>Fixed up the 'WG Web' and 'WG List' lines in YANG module(s)</li>
<li>Fixed up copyright (i.e., s/Simplified/Revised/) in YANG module(s)
</li>
</ul>
</section>
<section>
<name>12 to 13</name>
<ul spacing="normal">
<li>NO UPDATE.</li>
</ul>
</section>
<section>
<name>13 to 14</name>
<ul spacing="normal">
<li>Updated per Shepherd reviews impacting the suite of drafts.</li>
</ul>
</section>
<section>
<name>14 to 15</name>
<ul spacing="normal">
<li>Updated per Shepherd reviews impacting the suite of drafts.</li>
</ul>
</section>
<section>
<name>15 to 16</name>
<ul spacing="normal">
<li>Updated per Tom Petch review.</li>
<li>Added refs to RFC9293 and SOCKS 4A.</li>
<li>Fixed examples to use IETF-sanctioned values for examples.</li>
</ul>
</section>
<section>
<name>16 to 17</name>
<ul spacing="normal">
<li>Addresses AD review comments.</li>
<li>Added note to Editor to fix line foldings.</li>
<li>Added Security Considerations text to also look a SC-section from
imported modules.</li>
<li>Fixed bug: s/augment "keepalives"/refine "keepalives"/</li>
<li>Set defaults for idle-time, max-probes, and probe-interval (remove
d "mandatory true").</li>
<li>Updated examples to use IETF recommended values for examples.</li>
</ul>
</section>
<section>
<name>18 to 19</name>
<ul spacing="normal">
<li>Addresses AD review by Rob Wilton.</li>
</ul>
</section>
<section>
<name>18 to 19</name>
<ul spacing="normal">
<li>Replace RFC 1122 with RFC 9293.</li>
</ul>
</section>
<section>
<name>19 to 20</name>
<ul spacing="normal">
<li>Addresses 1st-round of IESG reviews.</li>
</ul>
</section>
<section>
<name>20 to 22</name>
<ul spacing="normal">
<li>Addresses issues found in OpsDir review of the ssh-client-server d
raft.</li>
<li>Updated to address Mallory Knodel's Gen-ART review.</li>
<li>Renamed Security Considerations section s/Template for/Considerati
ons for/</li>
<li>s/defines/presents/ in a few places.</li>
<li>Add refs to where the 'operational' and 'system' datastores are de
fined.</li>
<li>Added more 'feature' statements and descriptions for them</li>
<li>Added Security Considaration for the "password" node</li>
</ul>
</section>
<section>
<name>22 to 23</name>
<ul spacing="normal">
<li>Address IESG review comments.</li>
</ul>
</section>
<section>
<name>23 to 24</name>
<ul spacing="normal">
<li>Nothing changed. Bumped only for automation.</li>
</ul>
</section>
<section>
<name>24 to 25</name>
<ul spacing="normal">
<li>Updated to support dual-stacks</li>
</ul>
</section>
<section>
<name>25 to 26</name>
<ul spacing="normal">
<li>Updated to ensure at least one local-bind is specified.</li>
</ul>
</section>
</section>
<section numbered="false"> <section numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank the following for lively discussions <t>The authors would like to thank the following for lively discussions
on list and in the halls (ordered by first name): on list and in the halls (ordered by first name):
Éric Vyncke, <contact fullname="Éric Vyncke"/>,
Joe Clarke, <contact fullname="Joe Clarke"/>,
Jürgen Schönwälder, <contact fullname="Jürgen Schönwälder"/>,
Ladislav Lhotka, <contact fullname="Ladislav Lhotka"/>,
Mallory Knodel, <contact fullname="Mallory Knodel"/>,
Martin Duke, <contact fullname="Martin Duke"/>,
Michael Tüxen, <contact fullname="Michael Tüxen"/>,
Mohamed Boucadair, <contact fullname="Mohamed Boucadair"/>,
Nancy Cam-Winget, <contact fullname="Nancy Cam-Winget"/>,
Nick Hancock, <contact fullname="Nick Hancock"/>,
Per Andersson, <contact fullname="Per Andersson"/>,
Rob Wilton, <contact fullname="Rob Wilton"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Tom Petch, <contact fullname="Tom Petch"/>, and
Wim Henderickx. <contact fullname="Wim Henderickx"/>.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 187 change blocks. 
1011 lines changed or deleted 575 lines changed or added

This html diff was produced by rfcdiff 1.48.