YANG Groupings for TCP Clients and TCP Servers
draft-ietf-netconf-tcp-client-server-26

# Internet AD comments for draft-ietf-netconf-tcp-client-server-22
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S4.3

* "to listen on all IPv4 or IPv6 address." ->
  "to listen on all IPv4 or IPv6 addresses."

Similar to the ssh-server that defines keep-alives, I feel that if one believes keepalives are defined at this layer, that same layer should also define idle-timeout for a server.

Thank you to Nancy Cam-Winget for the SECDIR review.

** Section 5.1, .2 and .3 had the following reminder:

OLD
“Since the module in this document only define groupings, these considerations are primarily for the designers of other modules that use these groupings.”

Consider if something more direct such as the following could added to Section 5.0 to make it clear that enumerating all possible uses or sensitivities of these grouping is not possible and left to those who import these modules.  

NEW
The modules in this document define groupings and will not be deployed as standalone modules. Their security implications may be context dependent based on their use in other modules.  The designers of modules which import these grouping must conduct their own analysis of the security considerations.

** Section 5.1 and 5.3.  These sections indicate that there is no read or write sensitivities in modules ietf-tcp-common and ietf-tcp-server.

-- Per ietf-tcp-common, wouldn’t an attacker setting probe-interval=1 and idle-time=1 or max cause problems in certain networks?

-- Per ietf-tcp-server, wouldn’t reading the fields in tcp-server-grouping provide reconnaissance/targeting information for an attacker.  It seems like writing to these fields would break the configuration.

** Section 5.2.  This section indicates that there are no write sensitivities and only one read sensitivity.  Per ietf-tcp-client, wouldn’t writing to some of these fields break the configuring.  If given read access, could the list of available SOCKS provide service information to the attacker?

Thanks for addressing my main previous DISCUSS point about proxies. The text in the introduction is enough indeed (even if some words also in abstract would be welcome).

For easy archiving, here is a pointer to the previous DISCUS:
https://mailarchive.ietf.org/arch/msg/netconf/GLfFl9AzyUFI_2Kip4nNa5QNlOg/

Thanks to the authors for the easy and fast discussion and resolution.

EDIT: with another comment spurred by a different doc.

Thanks to Michael Tuexen for the TSVART review.

I support Eric's DISCUSS about support for HTTP CONNECT proxies, though I think MASQUE itself is not relevant here.

It's also important to indicate, probably in (2.1.5), that Keepalive MUST (SHOULD?) NOT be activated if there is application-level keepalive, as there is in SSH.

Nit:
(2.1.5) s/not universally accepted/not universally deployed? adopted? activated?

Accepted seems like an imprecise word here.