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 protected]
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
