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

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

Hi Joe,

In the YANG model, the statement “if-feature statistics;“ explicitly specifies that an implementation only has to support that if it supports the “feature” statistics of the model, for instance, if it announces that support (e.g., during the NETCONF handshake). It is entirely up to the implementer whether to support a given feature or not. This is just using the tools from the YANG language.

In addition, keep in mind that objects in a YANG model are optional by default. A node in the tree must only be present if the keyword “mandatory true” is specified in YANG. We don’t use this keyword in the model. So, for somebody who reads the YANG model, IMHO it should be more than clear that the model is optional.

We have discussed quite a bit how to address your past comment and this seems the most obvious approach to somebody who is familiar with YANG.

As a side note, we can see here that this is about details of the YANG language. One of the challenges with this doc is that one may need both some TCP and some YANG expertise to understand some of the details. Probably only very few people deal with both topics at the same time. For example, I am not a real YANG expert myself. But, well, I am not the only author of the I-D... The idea of the I-D is to bring together the needed expertise among the authors. (And there would still be room for more co-authors.) Also, for the TCPM working group probably some of the YANG details are less interesting. More relevant is probably how TCP configuration and stats are modelled, e.g., what parameters are used, what values parameters can take, how the parameters are described precisely, etc. And I think we have *a lot* of expertise on that in TCPM.

I am not sure how the TCP roadmap helps us with the YANG model, tough. It is unrealistic to model in YANG everything that the IETF has written on TCP so far. To make a trivial example: We don’t need a YANG model for Quick-Start TCP ;-) This is why the I-D takes the opposite approach: The focus is on configuration attributes and stats that exist on (several) existing TCP implementations. So, basically the proposal is to only model attributes that exist (in somewhat similar from) on several TCP stacks, i.e., it can be configured already, albeit not necessarily by YANG. This set of attributes mostly corresponds to what follows from the standards-track TCP specification, albeit of course the devil is in the details. In any case, to me it doesn’t make a lot of sense to model something in a YANG model that a corresponding NETCONF server implementation cannot implement because no relevant TCP stack supports it.

Thanks

Michael


From: Joseph Touch <[e-mail]>
Sent: Friday, March 27, 2020 5:49 PM
To: Scharf, Michael <[e-mail]>
Cc: Lars Eggert <[e-mail]>; [e-mail]; tcpm IETF list <[e-mail]>; Michael Tuexen <[e-mail]>
Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04




On Mar 27, 2020, at 8:51 AM, Scharf, Michael <[e-mail]<mailto:[e-mail]>> wrote:

Hi Joe,

Regarding stats, this is a YANG „feature“ in draft -04. That explicitly specifies that a NETCONF server compliant to the YANG model does not have to provide the stats. We added this because of your past comment on that.

AOK, but is that clear in the model itself? I.e., is there a way that merely using that subtree of data forces the user to realize that it’s explicitly optional?


For the stats, -04 relatively closely follows the TCP-MIB (and the WG explicitly ask not to try a 1:1 mapping).

AOK.

...
I fully agree that we can discuss every single entry. But, at least for the stats, I don’t think this is really a lot of work.

Agreed; this isn’t onerous esp. if optional.


In addition, there is one difference between a YANG model (and in fact also a MIB) and a TCP API: The TCP API is tightly coupled with the TCP protocol implementation typically in the kernel. Network management apps using YANG can run outside the kernel.

In-kernel or out-of-kernel are implementation decisions. Neither is driven by MIB vs YANG or even the TCP API (or TCP) itself, agreed.

My point is that we need to be careful to not make this model an explicit or implicit extension of the API. The optional part above should do that.


...
Stats, TCP-AO and MD5 (with appropriate flagging) actually look like pretty low-hanging fruits to me. Of course, we need to discuss the modeling details,  but it is a fairly narrow and well-defined scope. Is this part really the most challenging part of the document that prevents us from adopting a YANG model in TCPM?

The TCP roadmap should help us understand what’s critical and not in this model, IMO.

Joe