Hi Michael, I took a look at these, and thought a bit about our follow-up conversation after the meeting.
If I understand correctly, the suggestion here is to consider some alternative toolchains focused more on generating and working with APIs, rather than networking configuration, is that correct? I have a couple of points of response: 1. I think in my slides, I listed 5 points with 6 sub-points about the benefits of YANG (including the benefits of a standardized config format, and the benefits of YANG specifically). As far as I can see, tools like this might do a better job on one of the sub-points (API generation), but provide little or no support that speak to any of the other points and sub-points. 2. I also think standardizing on a toolchain like one of these would work against some of the other major goals of TAPS, particularly allowing implementations to use language-idiomatic constructs for the actual API provided by the implementation. In short, I think these tools work at the wrong layer of abstraction for what TAPS is trying to accomplish, since they seem to focus on the specifics of the calls in the API boundary. By contrast, a YANG-based approach mainly addresses the data that passes across the API boundary, while leaving abstract the specifics of the API. For particular implementations I think some of these tools would be really valuable, but I think the choice of which one works best for a particular implementation is much like the programming language choice, and best left to the implementors who are going to use it. So in my opinion, trying to standardize (in TAPS) a concrete API with tools like the suggested ones would be a step in the wrong direction. Thanks for clarifying the suggestion, and I hope that explains my position on it. I'm planning nothing more about following up on this, so please let me know if you think I've misunderstood something important about the suggestion or the tools you mentioned. Regards, Jake On 2019-03-29, 04:53, "Scharf, Michael" <[email protected]> wrote: As mentioned on the mic: There are quite a number of solutions to "rigorously" specify APIs. Some of these general-purpose techniques are IMHO also used for configuration/provisioning tasks in the networking industry, i.e., as alternative to YANG. In a former life, I had quite some discussions on the role of YANG as compared to, for instance: * swagger.io (https://swagger.io/) * gRPC, gNMI and protocol buffers (see e.g. draft-openconfig-rtgwg-gnmi-spec-01 in the IETF) In both cases there is are tooling eco-system that are IMHO widely used by app developers (and often preferred over YANG). The YANG tooling that exists in industry, e.g., for code auto-generation, is quite specific to network management, as far as I can tell. To me, whether to develop models in YANG or in other data modeling languages depends a lot on the use case and the target software developer community. Of course, in the RTG and OPS area YANG is the default data modeling language. Michael (as somebody who attends RTG and OPS working groups) _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
