Hi Jake, I certainly agree that YANG has a lot of benefits and I will not argue against using it.
I just observe that for modeling APIs, instead of modeling data stores for configuration and operational state in network elements, there are *many* other choices for language-independent API descriptions with excellent software tooling support. I should maybe have mentioned more explicitly Interface Definition Languages (IDLs), such as the ones listed on https://en.wikipedia.org/wiki/Interface_description_language. Note that both OpenAPI/Swagger and protobuf are listed on this page. And, well, YANG is not listed on that page... Of course, that may be a mistake of the Wikipedia page. But I believe it somewhat correlates with the knowledge of many software developers. Thanks Michael > -----Original Message----- > From: Holland, Jake <[email protected]> > Sent: Saturday, April 6, 2019 8:09 PM > To: Scharf, Michael <[email protected]>; [email protected] > Subject: Re: [Taps] Potential alternatives to YANG > > 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
