Subject: Re: [Taps] Potential alternatives to YANG

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Apr 2019 09:28:39 +0200 (CEST)

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: [email-masked]

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 18 Apr 2019 12:12:00 +0000

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

Yep, but I have mentioned protocol buffers, too. And I haven't mentioned other solutions in that space, such as Apache Thrift. By no means my list was meant to be comprehensive. BTW, I won't argue that other solutions indeed solve exactly the same problem like NETCONF/YANG - in fact, they do not.
 
> think using a good data modeling language is important, thus I think YANG

If one is not using NETCONF, YANG may not be the only data modeling language one could use. Having said this, YANG is clearly an *excellent* data modeling language, and probably the only relevant one in some areas of industry (e.g. on routers).

Personally, I am perfectly fine with using YANG.

Michael