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

Martin Bjorklund <> Fri, 07 June 2019 07:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E9411201A3 for <>; Fri, 7 Jun 2019 00:21:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4jNBUqXCvY7o for <>; Fri, 7 Jun 2019 00:21:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B8CF41201C9 for <>; Fri, 7 Jun 2019 00:21:56 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTPSA id 865F11AE0290; Fri, 7 Jun 2019 09:21:53 +0200 (CEST)
Date: Fri, 07 Jun 2019 09:21:53 +0200
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netconf] proposal for tcp-client-server draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Jun 2019 07:22:00 -0000


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.


Kent Watsen <> 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