Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

["Scharf, Michael" <[e-mail]>]

Hi Jake,

Speaking as one of the authors...

> -----Original Message-----
> From: Holland, Jake <[e-mail]>
> Sent: Wednesday, March 25, 2020 3:56 AM
> To: Michael Tuexen <[e-mail]>; tcpm IETF list <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-
> yang-tcp-04
> 
> Hi tcpm and authors,
> 
> I'd like to hear from the authors about their intentions with regard to
> "running code" to go with the development on this model.
> 
> I can imagine several valuable use cases for a model like this one,
> many of which are mentioned in the document, but I think the kinds of
> thing I'd hope to see in an "Implementation Status" section (or even
> an "Implementation Plans" section) would make a big difference to me on
> whether I support adoption at this time or not.

TCPM typically documents the implementation status in the shepherds write-up after WGLC. As such information can easily get outdated, any text in an RFC would be a snapshot at best. TCPM has such sections in some documents (e.g., currently 2140bis), but it requires care. More on that below.

In contrast, I personally don't see a big value of a section "implementation plans" in an RFC, and not even in an I-D. Plans for the future can be discussed on the list (like this e-mail), in meetings, etc. And predictions of the future are hard ;-)
 
BTW, as far as I can see, many working groups in the IETF publish YANG models on standards-track without such a section. One of the root causes may be that "running code" for a data model is not exactly the same as an implementation of a protocol (i.e., what TCPM usually deals with). Again, more on that below.

> I think a model like this one would be useful, but I'm not confident I
> can usefully review a model like this as a standalone entity from first
> principles by reading through it, and so if that's what we'd be signing
> tcpm up to do, I'd rather defer adoption.

Indeed, implementation feedback helps *a lot*. I keep telling this repeatedly when I wear another hat. So, I hear you.

Yet, I believe this is something to be looked at when it comes to starting a WGLC. We are not there yet...

Deferring WG adoption would probably create an incentive for other working groups to model TCP in their own YANG models. This would probably happen soon for parts of the proposed model (e.g., TCP-AO) that are needed by other working groups. In that case, TCPM contributors would most likely have to review YANG models from other WGs during IETF last call. In other words, reviews of YANG models will be needed in any case. In that situation, at least to me it sounds a better idea that TCPM owns the YANG model.

> On the other hand, if somebody currently is writing or wants to write,
> for instance, a way to translate back and forth between yang instance
> data and the sysctls in a widely used operating system or 2, and will be
> providing a review of which settings are and are not compatible with the
> model to the wg as the development progresses, then I'm _highly_
> supportive of adoption.  If that's the situation, I expect seeing
> examples and usage will provide enough meat to make a meaningful review
> possible.

I think these are two separate (but related) questions:

1/ Whether the YANG data model can be mapped to existing YANG models (e.g. on routers) or sysctls (e.g. on host operating systems).

This is a comparison of different data models that does not require an actual "implementation" of the YANG data model. It is only about the syntax and semantics of objects and functions. I have already performed on paper such a (partial) analysis based on the documentation of several widely used operating systems.

The results are summarized on slide 3 in 
https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-yang-groupings-for-transmission-control-protocol-tcp-configuration-01.

The stacks I analyzed for that slide were Linux, FreeBSD and Windows and existing YANG models from Cisco IOS-XE. We could add a table with such information e.g. to an appendix of the I-D. Would such a comparison table in the I-D help to address your concern? 

Note that the TCPM community would probably want to ensure that such a table is indeed correct at the time of publication. This requires more eyes and it is actually one of the reasons why TCPM may want to own the content of the document by adopting it.

2/ Whether it is possible to write a NETCONF server (or RESTCONF server) that indeed implements the YANG data model for configuring an existing TCP stack.

As far as I understand, "implementation" of a YANG data model requires a corresponding NETCONF (or RESTCONF) protocol implementation in order to actually change configuration, read counters, etc. A full NETCONF server requires much more than an instance of the YANG data model, as NETCONF has lots of functionality.

As I personally believe that running code matters in TCPM, I have been thinking quite a bit about such a NETCONF implementation already. I think a NETCONF server with the TCP YANG data model is doable e. g. on Linux *as a prototype*. Keep in mind that a NETCONF server is typically a user-space management application that runs outside the kernel, i.e., it is actually not tightly coupled to code in the TCP stack. It is an app. If no other implementation emerges, my own plan would be to develop such an app at least as proof-of-concept before a WGLC in TCPM and to report the findings so that they can be documented e.g. in the shepherd write-up. Would this plan work for you? 

> I just don't know which of those situations is closer to being the case
> here. 

I would argue that we are closer to the second situation. But, of course, there is only so much authors of a document can do when it comes to running code.

Best regards

Michael

> Please forgive me if this has been covered already in previous tcpm
> meetings, but I missed it if it was.
> 
> Best regards,
> Jake
> 
> On 3/16/20, 1:45 PM, "Michael Tuexen" <[e-mail]> wrote:
> 
>     Dear all,
> 
>     this mail starts a WG adoption call for
>     https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-04
> 
>     So I would like to solicit feedback regarding support for or objections against
> the
>     adoption of the document as a WG document in TCPM.
> 
>     Please provide feedback before March 31st.
> 
>     For the context and current state of the document, see the presentation sent
> yesterday
>     to the mailing list by Mahesh.
> 
>     Best regards
>     Michael
> 
> 
>