Re: [netconf] proposal for tcp-client-server draft

[Martin Bjorklund <[e-mail]>]

Hi,

If at all possible, I think we should not include more features in
these models, but instead try to get them finished with the features
they have.  This said, if you believe the fundamental design needs to
be changed to accomodate for things like NAT etc, then perhaps it is
better to do this now.


/martin



Kent Watsen <[e-mail]> wrote:
> 
> 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
> 
>