Re: [Taps] Potential alternatives to YANG

["Holland, Jake" <[e-mail]>]

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" <[e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/taps