YANG Groupings for
TCP Clients and TCP ServersWatsen Networkskent+ietf@watsen.net
Operations
NETCONF Working GroupThis document defines two YANG modules: the first defines a grouping
for configuring a generic TCP client, and the second defines a grouping
for configuring a generic TCP server. It is intended that these
groupings will be used by applications using the TCP protocol.This draft contains many 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.Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: 2019-04-07 --> the publication
date of this draftThe following Appendix section is to be removed prior to publication:
Appendix A. Change LogThis document defines two YANG 1.1 modules:
the first defines a grouping for configuring a generic TCP client, and
the second defines a grouping for configuring a generic TCP server. It
is intended that these groupings will be used by applications using
the TCP protocol. For instance, these groupings could help define
the configuration module for an SSH, TLS, or HTTP based application.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
when, and only when,
they appear in all capitals, as shown here.This section provides a tree diagram for
the "ietf-tcp-client" module.This section presents an example showing the tcp-client-grouping
populated with some data.This YANG module has normative references to .This section provides a tree diagram for
the "ietf-tcp-server" module.This section presents an example showing the tcp-server-grouping
populated with some data.This YANG module has normative references to .The YANG modules defined in this document are designed to be accessed
via YANG based management protocols, such as NETCONF and RESTCONF . Both of these
protocols have mandatory-to-implement secure transport layers (e.g.,
SSH, TCP) with mutual authentication.The NETCONF access control model (NACM)
provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and
content.Since the modules defined in this document only define groupings,
these considerations are primarily for the designers of other modules
that use these groupings.There are a number of data nodes defined in the YANG modules that are
writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability: Some of the readable data nodes in the YANG modules may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data nodes
and their sensitivity/vulnerability: This document does not define any RPC actions and hence this section
does not consider the security of RPCs.This document registers two URIs in the "ns" subregistry of the
IETF XML Registry . Following the format in
, the following registrations are
requested:This document registers two YANG modules in the YANG Module Names
registry . Following the format in , the following registrations are requested: