Last Call Review of draft-ietf-netconf-tcp-client-server-09
review-ietf-netconf-tcp-client-server-09-yangdoctors-lc-lhotka-2021-04-09-00

The modules are well designed and nicely documented, both in the descriptions
and text of the Internet-Draft.

**** Comments

- Sections 2.1.4, 3.1.3, 4.1.3: the sentence 'The "..." module does not contain
any protocol-accessible nodes.' is misleading in that the modules do define
data nodes that are intended to be protocol accessible after the corresponding
grouping is used. I know this is a part of the NETCONF/YANG lingo, but another
formulation that clearly says what's going on might be preferable.

- Sections 2.2, 3.2 and 4.2: the XML snippets use document elements
"tcp-common", "tcp-client" and "tcp-server", but these containers are not
defined in the corresponding modules. This is confusing, my suggestion is to
rewrite the examples in the JSON representation where no such top-level node is
necessary.

- What is the purpose of "tcp-connection-grouping" if it only uses
"tcp-common-grouping" and nothing else? Why cannot "tcp-common-grouping" be
used directly?

- The "local-port" parameter defined in ietf-tcp-client seems dubious from the
security viewpoint in that fixing the source port makes it easier for attackers
to steal the connection (see RFC 6056). If the feature
"local-binding-supported" is needed at all, I'd suggest to mention this in
Security Considerations.

- The module ietf-tcp-client uses the placeholder "RFC AAAA", which is not
defined in the Editorial Note.

**** Nits

- RFC 7950 is cited repeatedly (6 times) in a general context, e.g. whenever
YANG 1.1 is mentioned. It should suffice to use the citation at the first
appearance.

- sec. 1.3: s/in compliant/is compliant/

- in 3 places: s/illustatrating/illustrating/