Skip to main content

Last Call Review of draft-ietf-netconf-tcp-client-server-09

Request Review of draft-ietf-netconf-tcp-client-server
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2021-04-16
Requested 2021-03-26
Requested by Mahesh Jethanandani
Authors Kent Watsen , Michael Scharf
Draft last updated 2021-04-09
Completed reviews Yangdoctors Last Call review of -09 by Ladislav Lhotka (diff)
Assignment Reviewer Ladislav Lhotka
State Completed
Review review-ietf-netconf-tcp-client-server-09-yangdoctors-lc-lhotka-2021-04-09
Posted at
Reviewed revision 09 (document currently at 15)
Result Ready with Issues
Completed 2021-04-09
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

- 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

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

- in 3 places: s/illustatrating/illustrating/