Re: [Taps] Potential alternatives to YANG

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

Hi Michael,

This response leads me to believe maybe we aren't fully understanding each other's
positions, and are perhaps talking past each other.

Maybe I haven't been clear enough explaining my position:
My claim is that the data store for networking-specific configuration and
operational state is what's most worth modeling as part of the TAPS effort.
(And probably NOT the calls in the API itself.)

Do you think that captures our disconnect, or do you think it's something else?

If it does roughly capture the disconnect, a couple of follow-up questions:
- do you disagree with this position?
- do you think that if you became convinced of this position, that YANG would
  be clearly preferred to the other systems you've pointed out?

I'm happy to discuss further (if needed) once we've nailed down what exactly needs
better explanation and consensus, but I didn't want to get too sidetracked if I've
misunderstood where we disagree.

Thanks and regards,
Jake

On 2019-04-16, 07:35, "Scharf, Michael" <[e-mail]> wrote:

    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 <[e-mail]>
    > Sent: Saturday, April 6, 2019 8:09 PM
    > To: Scharf, Michael <[e-mail]>; [e-mail]
    > 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" <[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
    >