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

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 26 Mar 2019 13:02:49 +0000

Hi Mahesh,

As chair of the TCPM working group, I believe that the document draft-kwatsen-netconf-tcp-client-server-00 belongs into the TCPM working group. The document is about a generic YANG model for an interface for TCP "for an SSH, TLS, or HTTP based application". I fail to see a reason why such a generic TCP model should be done in NETCONF.

Thus, as a chair of TCPM, I object to adoption in NETCONF.

I also want to note that it would have been possible to send a note to the TCPM list prior to starting an adoption call, as the TCPM list is monitored by many TCP implementers who could be affected by such a YANG model. YANG models can be used in different use cases. TCPM has a tradition of being very open to presentations from other working groups if they relate to TCP. I have added the TCPM list in CC.

As an individual contributor to the IETF, I happen to be an author of draft-scharf-tcpm-yang-tcp, which actually was submitted last year. Given that different working groups seem to be involved, I believe that it would make sense to join efforts. Shouldn't we have a chat on the best next steps?

Thanks

Michael

> -----Original Message-----
> From: netconf <[email-masked]> On Behalf Of Mahesh
> Jethanandani
> Sent: Tuesday, March 26, 2019 12:17 PM
> To: Netconf <[email-masked]>
> Subject: [netconf] Adoption poll for tcp-client-server and http-client-server
> draft
> 
> This is the start of a two week poll for WG adoption of the two drafts:
> 
> https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00
> https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00
> 
> Please indicate your support for or any objections you might have for
> adopting the two drafts as WG items by April 9.
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Mar 2019 15:19:05 +0100

Dear Michael,

please note that a configuration model for NETCONF is on the NETCONF
charter for ~5 years. To establish NETCONF session, we obviously need
to establish TCP connections. This is what this work does. It is
entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about
TCP protocol engine internals. If the TCPM chair has an issue with a
generic solution to establish TCP connection not being done in TCPM,
we should perhaps just hardcode how to establish TCP connections for
NETCONF and RESTCONF and call it the day and then TCPM can pick up the
pieces and start work on a generic solution.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Mar 2019 14:52:42 +0000

Wait, I don’t think we need to do anything drastic here.

Michael, please note that the TCP modules here are intended to be very limited in scope, just the bare minimum necessary to support the NETCONF/RESTCONF that (in case you don’t know) are layered on top of SSH and TLS, and hence TCP.  The bare minimum appears to be just addresses, ports, and keep-alives.   The NETCONF WG has NO interest in extending this module beyond this minimal amount.

Additionally, please see Slide 9 here [1] and note that this module is part of a rather large eco-system of interrelated modules.  The point being is that the reason for it being  structured the way it is (e.g., as groupings) is pretty well justified.

My proposal is as follows:

  1) Let’s (as co-authors) get the draft-kwatsen-netconf-tcp-client-server-00
      with it’s current scope to RFC status ASAP (a couple months), so that this
      five-year NETCONF project can end.  Happy to tweak it as you see fit.  
      Which WG does this is not important, but for a time-expediency perspective,
      I recommend the NETCONF WG due to the heavy interlinking mentioned
      before.

  2) TCPM takes over the RFC, publishing a bis with all the extra parameters
       that are in draft-scharf-tcpm-yang-tcp.  TCPM could even do this work
       in parallel, so as to not cause any scheduling delays.

Thoughts?  Can we have a short-term collaboration and then let TCPM take over?

[1] https://datatracker.ietf.org/meeting/104/materials/slides-104-netconf-crypto-types-clientserver-suite-of-drafts-00.pdf

PS: Let’s (+ co-chairs) meet up today/tomorrow.

Kent // contributor 

> On Mar 26, 2019, at 3:19 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Dear Michael,
>

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 26 Mar 2019 14:54:36 +0000

Hi Juergen,

The document includes TCP keepalives configuration and this is actually about TCP protocol engine internals, no?

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. 

Michael

> From: Juergen Schoenwaelder <[email-masked]>
> Sent: Tuesday, March 26, 2019 3:19 PM
> To: Scharf, Michael <[email-masked]>
> Cc: Mahesh Jethanandani <[email-masked]>; Netconf
> <[email-masked]>; [email-masked]
> Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-
> server draft
> 
> Dear Michael,
> 
> > As chair of the TCPM working group, I believe that the document draft-
> kwatsen-netconf-tcp-client-server-00 belongs into the TCPM working group.
> The document is about a generic YANG model for an interface for TCP "for an
> SSH, TLS, or HTTP based application". I fail to see a reason why such a generic
> TCP model should be done in NETCONF.
> >
> > I also want to note that it would have been possible to send a note to the
> TCPM list prior to starting an adoption call, as the TCPM list is monitored by
> many TCP implementers who could be affected by such a YANG model.
> YANG models can be used in different use cases. TCPM has a tradition of
> being very open to presentations from other working groups if they relate to
> TCP. I have added the TCPM list in CC.
> >
> > As an individual contributor to the IETF, I happen to be an author of draft-
> scharf-tcpm-yang-tcp, which actually was submitted last year. Given that
> different working groups seem to be involved, I believe that it would make
> sense to join efforts. Shouldn't we have a chat on the best next steps?
> >
> > Thanks
> >
> > Michael
> >
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Mar 2019 16:34:03 +0100

> 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.
 
> 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.

/js

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 26 Mar 2019 15:53:39 +0000

> Sent: Tuesday, March 26, 2019 4:34 PM

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.
> >
> 

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.

Michael

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Mar 2019 17:10:39 +0100

> 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…

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 26 Mar 2019 16:21:04 +0000

> Sent: Tuesday, March 26, 2019 5:11 PM
> > 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.
> >
> > 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.
> >
> 

Standardizing generic groupings including protocol-specific configuration without talking to the working group owning the protocol is probably not the right approach - no matter what the protocol is and where it is homed in the IETF.

As a TCPM chair, I speak up because I believe such a document needs to be reviewed by TCP implementers early. That expertise can be found in TCPM.

Note that it is perfectly possible that the TCPM working group decides that the specific problem at hand does not have to be solved in TCPM. We could have discussed that yesterday in TCPM.

Michael

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 29 Mar 2019 08:59:05 +0000

Hi Kent,

As already noted during our very useful hallway discussion, I am fine with this proposal (both as chair and as individual contributor). I believe that the draft should be presented in TCPM in Montreal so that the TCPM community can review the model and discuss potential next steps. The TCPM community can then decide e.g. whether a joint WGLC will be useful. As usual in TCPM, the chairs will carefully listen to feedback from TCP implementers.

As long as proper review by TCP implementers is ensured and as long as we can come up with a future-proof solution, it is actually not important to me which WG publishes draft-kwatsen-netconf-tcp-client-server-00.

I have some technical questions on the model and its structure (e.g., why the parameter “idle-time” is measured in minutes instead of seconds). Let’s sort that out offline.

Thanks

MIchael

PS: A personal comment mostly to the TCPM community: Unfortunately I have not been aware of draft-kwatsen-netconf-tcp-client-server-00 prior to Tuesday and this is why I have not mentioned the I-D during my talk in TCPM on Monday. I follow quite a bit of working groups outside TSV area, but I was quite busy in the weeks prior to the meeting and thus I missed the submission of this draft. If I had been aware of the I-D, I would obviously have invited Kent to present the document in TCPM in Prague, as one example of emerging TCP-related YANG models that TCPM should perhaps be aware of.

From: Kent Watsen <[email-masked]>
Sent: Tuesday, March 26, 2019 3:53 PM
To: Juergen Schoenwaelder <[email-masked]>
Cc: Scharf, Michael <[email-masked]>; [email-masked]; Netconf <[email-masked]>
Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft

Kent // contributor

On Mar 26, 2019, at 3:19 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
Dear Michael,

/js

Hi Mahesh,

Thanks

Michael

-----Original Message-----
From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Mahesh
Jethanandani
Sent: Tuesday, March 26, 2019 12:17 PM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: [netconf] Adoption poll for tcp-client-server and http-client-server
draft

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf