Hi Jake, > 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.
Actually I think we fully agree on that. > (And probably NOT the calls in the API itself.) +1 > Do you think that captures our disconnect, or do you think it's something > else? Well, I don't think there is a disconnect. I don't disagree to use of YANG. We all know that it is a very powerful data modeling language with *many* cool features. I'd just like to ensure that the pros and cons of using YANG in this specific context are well understood. As far as I can tell, YANG has been built for mostly for NETCONF (and RESTCONF) and I believe that this has influenced design decisions. As noted in Section 1.1 of draft-jholland-taps-api-yang, NETCONF (or RESTCONF) may not be the key focus for TAPS. So, unlike for many other data modeling use cases in the IETF focusing on NETCONF/RESTCONF, one *could* raise the question whether YANG is indeed the best data modeling language. As an IETF contributor believing in IETF technology, I am perfectly fine with answering "Yes". > 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? Let me state once again: I am perfectly fine with using YANG. Otherwise I would hardly look myself into YANG models for TCP... Anyway, I am not working on running code, i.e., my opinion does not matter much in reality. The important question is if owners of running code that shall make use of TAPS would agree that YANG is the "clearly preferred system". I simply don't know that. But I have dealt in the past with sectors of industry that would be able to give quite a number of reasons why the answer to that question would be "no", in particular if the use case is not tied to NETCONF/RESTCONF. I don't know if others in the TAPS working group have made similar experiences. In any case, those use cases were quite different to TAPS, and so maybe whatever I have seen in the past may not be relevant at all. Thanks Michael > 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" <Michael.Scharf@hs- > esslingen.de> > > 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
