Re: [Taps] Potential alternatives to YANG

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 <jholland@akamai.com>
> Sent: Saturday, April 6, 2019 8:09 PM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; taps@ietf.org
> 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
>     Taps@ietf.org
>     https://www.ietf.org/mailman/listinfo/taps
> 