Hi Michael, This response leads me to believe maybe we aren't fully understanding each other's positions, and are perhaps talking past each other.
Maybe I haven't been clear enough explaining my position: My claim is that the data store for networking-specific configuration and operational state is what's most worth modeling as part of the TAPS effort. (And probably NOT the calls in the API itself.) Do you think that captures our disconnect, or do you think it's something else? If it does roughly capture the disconnect, a couple of follow-up questions: - do you disagree with this position? - do you think that if you became convinced of this position, that YANG would be clearly preferred to the other systems you've pointed out? I'm happy to discuss further (if needed) once we've nailed down what exactly needs better explanation and consensus, but I didn't want to get too sidetracked if I've misunderstood where we disagree. Thanks and regards, Jake On 2019-04-16, 07:35, "Scharf, Michael" <[email protected]> wrote: 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
