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

From: Michael Tuexen <[email-masked]>
Date: Mon, 16 Mar 2020 21:44:16 +0100

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

---

From: <[email-masked]>
Date: Tue, 17 Mar 2020 06:19:10 +0000

Hi Michael, all, 

I support adopting this draft.  

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de Michael Tuexen
> Envoyé : lundi 16 mars 2020 21:44
> À : tcpm IETF list
> Cc : [email-masked]
> Objet : [tcpm] Request for feedback on WG adoption of draft-scharf-
> tcpm-yang-tcp-04
> 
> Dear all,
> 
> So I would like to solicit feedback regarding support for or
> objections against the adoption of the document as a WG document in
> TCPM.
> 
> For the context and current state of the document, see the
> presentation sent yesterday to the mailing list by Mahesh.
> 
> Best regards
> Michael
>

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 25 Mar 2020 02:56:11 +0000

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.

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.

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 just don't know which of those situations is closer to being the case
here.

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" <[email-masked]> wrote:

    Dear all,

    

    Best regards
    Michael

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 25 Mar 2020 09:59:52 +0000

Hi Jake,

Speaking as one of the authors...

> -----Original Message-----
> From: Holland, Jake <[email-masked]>
> Sent: Wednesday, March 25, 2020 3:56 AM
> To: Michael Tuexen <[email-masked]>; tcpm IETF list <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-
> yang-tcp-04
> 
> Hi tcpm and authors,
> 

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.

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

> examples and usage will provide enough meat to make a meaningful review

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

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

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 25 Mar 2020 10:22:31 +0000

Hi Michael,

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

I think this would be a helpful addition during evaluation of the draft, though
I won't insist on it.  I'm ambivalent on whether it's got enough value to include
in the final RFC, since much of it will presumably go out of date at some point.

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

Great, that addresses my concerns.

I support adoption, I think a standardized set of config and stats for TCP
would be very useful and could dramatically improve portability.

Thanks and regards,
Jake

---

From: Lars Eggert <[email-masked]>
Date: Fri, 27 Mar 2020 14:40:34 +0200

Hi,

> https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-04
...
> Please provide feedback before March 31st.

I (still) don't believe this is worthwhile for the WG to take on.

My view here is very much biased by the disaster that were (are?) the TCP SNMP MIBs. Besides needing two attempts to get it right (RFC4022 followed by RFC4898), it took five years of WG time and produced work that AFAICT never really mattered, and quickly became stale.

I don't see any indications that a YANG model for TCP wouldn't follow the same course. Are there any stacks that indicated they were going to implement this? Who wants this?

Thanks,
Lars

---

From: <[email-masked]>
Date: Fri, 27 Mar 2020 13:01:20 +0000

Hi Lars, 

Many YANG modules are already including TCP-specific components. Some of these are already cited in the draft. These components are defined outside tcpm, with little if not no review at all from tcpm. Re-using some of the components defined in these documents may not be straightforward. 

Defining here in tcpm the groupings that can be re-used by other modules is more than appropriate. This is also to help developers of other modules.  

Cheers,
Med

> De : tcpm [mailto:[email-masked]] De la part de Lars Eggert
> Envoyé : vendredi 27 mars 2020 13:41
> À : Michael Tuexen
> Cc : [email-masked]; tcpm IETF list
> Objet : Re: [tcpm] Request for feedback on WG adoption of draft-
> scharf-tcpm-yang-tcp-04
> 
> Hi,
> 
> ....
> My view here is very much biased by the disaster that were (are?) the
> TCP SNMP MIBs. Besides needing two attempts to get it right (RFC4022
> followed by RFC4898), it took five years of WG time and produced work
> that AFAICT never really mattered, and quickly became stale.
> 
> I don't see any indications that a YANG model for TCP wouldn't follow
> the same course. Are there any stacks that indicated they were going
> to implement this? Who wants this?
> 
> Thanks,
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 27 Mar 2020 15:05:40 +0200

> Defining here in tcpm the groupings that can be re-used by other modules is more than appropriate. This is also to help developers of other modules.

If you replace "YANG module" with "SNMP MIB" in what you wrote, you get exactly the argument that was made for why TSV should be doing MIBs.

Lars

---

From: <[email-masked]>
Date: Fri, 27 Mar 2020 13:31:30 +0000

Re-,

I think that you missed the key point from my message: Grouping and reuse of modules. 

I'm not sure how this would apply for MIBs. Can you please tell me what is the equivalent of "uses"/"refine" statement with MIBs? 

Thank you. 

Cheers,
Med

> De : Lars Eggert [mailto:[email-masked]]
> Envoyé : vendredi 27 mars 2020 14:06
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Michael Tuexen; [email-masked]; tcpm IETF
> list
> > Many YANG modules are already including TCP-specific components.
> Some of these are already cited in the draft. These components are
> defined outside tcpm, with little if not no review at all from tcpm.
> Re-using some of the components defined in these documents may not be
> straightforward.
> >
> > Defining here in tcpm the groupings that can be re-used by other
> modules is more than appropriate. This is also to help developers of
> other modules.
> 
> If you replace "YANG module" with "SNMP MIB" in what you wrote, you
> get exactly the argument that was made for why TSV should be doing
> MIBs.
> 
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 27 Mar 2020 15:47:49 +0200

> I think that you missed the key point from my message: Grouping and reuse of modules.

The point I was trying to make is that with MIBs, a similar argument was made that TCP stuff was being put into MIBs elsewhere in the IETF, and that TSV should therefore do a TCP MIB instead. And we did (twice), it took forever, and then saw little use.

Lars