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/