Re: [Taps] Potential alternatives to YANG

[Mikael Abrahamsson <[e-mail]>]

On Fri, 29 Mar 2019, Scharf, Michael 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)

I thought gRPC and gNMI was equivalent to netconf, not to YANG?

> 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.

My experience is that people typically will take whatever there is lots of 
tooling for and it's "easy to use". Then as they use it more and more 
extensively, they discover all limitations and demand the tool is 
extended/enhanced. People will say "oh, JSON is so easy to work with" and 
after a while they discover that data models is good for 
defining/validating what goes on the wire, and now all of a sudden after a 
while you've invented all the "complication" of YANG.

Personally it's not super important to me that NETCONF is used, but I do 
think using a good data modeling language is important, thus I think YANG 
modeling is important.

The same way a huge amount of work has gone into XML, a huge amount of 
work has gone into YANG, to make sure it's well defined and works from 
lots of aspects.

-- 
Mikael Abrahamsson    email: [e-mail]