[netconf] proposal for tcp-client-server draft

[Kent Watsen <[e-mail]>]

Folks,

I'm working on a project for which the server is behind a NAT (e.g., a load balancer and/or TLS terminator), and the server needs to sometimes send out messages containing respond-back contact information (e.g., a URL to confirm the activation of a user account).  In these cases, the hostname/address it sends is not its native value, but rather the value used by the NAT fronting it.  Furthermore, the server may have multiple interfaces, each with different values (e.g., NBI, SBI, EBI, etc.), each potentially fronted by a NAT.  Using the client-server stacks, it makes sense to capture this information in the TCP-server model, the lowest common denominator.   While my application-level model could augment-in nodes to capture the NAT-ed values, the scenario seems common enough to warrant placement in the base model, albeit enabled by a feature-statement.  I'm thus planning to include some provision for this in the next TCP-server model update, so that it is captured and thoroughly discussed later.

FWIW, I'm tempted to make a symmetric update to the TCP-client model to support outbound proxies.  For instance, the ietf-http-client module already has a "proxy-server" node; however that node contains TLS/HTTP client/server authentication parameters, which would be inappropriate to capture in a TCP-level node.  For this reason, I'm not planning to make the symmetric TCP-client change, but rather leave it here as something for folks to ponder.

Kent  // contributor