Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Mar 26, 2019 at 03:53:39PM +0000, Scharf, Michael wrote:
> > -----Original Message-----
> > From: Juergen Schoenwaelder <[e-mail]>
> > Sent: Tuesday, March 26, 2019 4:34 PM
> > To: Scharf, Michael <[e-mail]>
> > Cc: Mahesh Jethanandani <[e-mail]>; Netconf
> > <[e-mail]>; [e-mail]
> > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-
> > server draft
> > 
> > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote:
> > > Hi Juergen,
> > >
> > > The document includes TCP keepalives configuration and this is actually
> > about TCP protocol engine internals, no?
> > 
> > I think we are talking about a client or server using setsockopt()
> > calls. This is not about globally changing TCP engine behavior.
> 
> There is a grey area between setsockopt() style configuration and TCP stack configuration. And one can easily end up in the question if other parameters of the TCP stack need to be optimized in an actual NETCONF/RESTCONF implementation for some reason, possibly on a per-connection basis. Then one gets into details of the TCP stack.
>  
> > > And I fail to see the benefit of doing TCP YANG modeling specific to
> > NETCONF or RESTCONF. For instance, on a router, I believe that NETCONF,
> > RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly all
> > other TCP-based protocols running on the NE. And if HTTP is included, YANG
> > models have a pretty broad applicability beyond routers. So what makes
> > NETCONF or RESTCONF so special that NETCONF needs its own model?
> > >
> > > As I mentioned, in the last years TCPM has been extremely open to TCP-
> > related needs in other working groups and we have quite successful cross-
> > area work.
> > >
> > 
> > The models are not NETCONF/RESTCONF specific unless process forces us
> > to make them NETCONF/RESTCONF specific. What makes
> > NETCONF/RESTCONF
> > special is that we started this 5 years ago. I do not care at the end
> > who owns the document as long as process does not bring us more delay.
> 
> It is reasonable to ask for a fast solution. And, well, a solution will be actually be faster if there are no "surprises" late in the publication process. So it may be better to discuss early what the best approach would be, and where to home what.
>

We had objects to configure TCP connections over which we run TLS and
SSH over which we run RESTCONF and NETCONF in the making for ~5 years.
And I also know RFCs that include YANG objects to establish TCP connections.
Is the keep alive the reason for TCPM to claim control of this? Or the
fact that we moved to more generic groupings?

Anyway, I am just saying you should be aware of the history and scope
of this work and then the WG chairs can settle this somehow.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>