Subject: Re: [Taps] Potential alternatives to YANG

From: "Holland, Jake" <[email-masked]>
Date: Sat, 6 Apr 2019 18:09:25 +0000

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 16 Apr 2019 14:35:16 +0000

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 <[email-masked]>
> Sent: Saturday, April 6, 2019 8:09 PM
> To: Scharf, Michael <[email-masked]>; [email-masked]
> Subject: Re: [Taps] Potential alternatives to YANG
> 
> Hi Michael,
> 
>     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 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

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 17 Apr 2019 01:29:14 +0000

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

    Hi Jake,

    
    
    Thanks
    
    Michael

---

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

Hi Jake,

> operational state is what's most worth modeling as part of the TAPS effort.

Actually I think we fully agree on that.

> (And probably NOT the calls in the API itself.)

+1

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

Well, I don't think there is a disconnect. I don't disagree to use of YANG. We all know that it is a very powerful data modeling language with *many* cool features.

I'd just like to ensure that the pros and cons of using YANG in this specific context are well understood. As far as I can tell, YANG has been built for mostly for NETCONF (and RESTCONF) and I believe that this has influenced design decisions. As noted in Section 1.1 of draft-jholland-taps-api-yang, NETCONF (or RESTCONF) may not be the key focus for TAPS. So, unlike for many other data modeling use cases in the IETF focusing on NETCONF/RESTCONF, one *could* raise the question whether YANG is indeed the best data modeling language. As an IETF contributor believing in IETF technology, I am perfectly fine with answering "Yes".

>   be clearly preferred to the other systems you've pointed out?

Let me state once again: I am perfectly fine with using YANG. Otherwise I would hardly look myself into YANG models for TCP...

Anyway, I am not working on running code, i.e., my opinion does not matter much in reality. The important question is if owners of running code that shall make use of TAPS would agree that YANG is the "clearly preferred system". I simply don't know that. But I have dealt in the past with sectors of industry that would be able to give quite a number of reasons why the answer to that question would be "no", in particular if the use case is not tied to NETCONF/RESTCONF. I don't know if others in the TAPS working group have made similar experiences. In any case, those use cases were quite different to TAPS, and so maybe whatever I have seen in the past may not be relevant at all.

Thanks

Michael

>     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
> 
> 
>     > On 2019-03-29, 04:53, "Scharf, Michael" <Michael.Scharf@hs-
> esslingen.de>
>     > wrote:
>     >
>     >     * gRPC, gNMI and protocol buffers (see e.g. draft-openconfig-rtgwg-
> gnmi-
>     > spec-01 in the IETF)
>     >

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 18 Apr 2019 21:44:32 +0000

Hi Michael,

Responses inline with [JH].

> Actually I think we fully agree on that.

[JH] Excellent, thanks for helping me clear that up.  I'm glad to have avoided
a rathole there.
    
> I'd just like to ensure that the pros and cons of using YANG in this specific context are well understood.

[JH] I won't claim that I fully understand the pros and cons of YANG as opposed
to a wide range of other possible choices, but rather that I'm confident that
YANG is a good enough choice that we can get good value by using it.

> As far as I can tell, YANG has been built for mostly for NETCONF (and RESTCONF) and I believe that this has influenced design decisions.

[JH] OK, that's interesting.

I'd be happy to drop this thread, so before answering this, first please take a
look at the rest of this message to see if you think it's worth digging deeper
here.

But if this discussion does seem worth continuing, could you point to some of the
design decisions that were driven by NETCONF and RESTCONF, and an example or 2 of
how at least one of the other modeling languages has a better design because it
wasn't subject to these effects?  (And if known, the impact that has on the
developers who use it?)

> So, unlike for many other data modeling use cases in the IETF focusing on NETCONF/RESTCONF, one *could* raise the question whether YANG is indeed the best data modeling language.

[JH] The framing of "best" leads me to wonder if this discussion is an instance
of "the perfect as enemy of the good"?

Anyway, I think I have a few main responses here:

1. Evaluating a bunch of modeling languages sounds like a lot of work, and
   I expect that if we did it, we'd conclude for each language that it's
   marginally better in some ways and worse in others, and that none of them
   rise substantially above "good enough".
2. YANG has one unique advantage, which is that other networking standards provide
   some useful definitions of relevant data types, which can be easily included by
   reference into a YANG data model.  (This is the main reason for my lightly held
   belief that YANG is probably the best available choice.)
3. Moving forward with the YANG model doesn't stop anyone from proposing another
   model in another language also, and if that model turns out better, we can just
   use it after we see it.  If that happens, it seems like less wasted work than a
   thorough evaluation of alternate modeling languages before getting started,
   especially if we end up with the same choice.

> But I have dealt in the past with sectors of industry that would be able to give quite a number of reasons why the answer to that question would be "no", in particular if the use case is not tied to NETCONF/RESTCONF. I don't know if others in the TAPS working group have made similar experiences.

[JH] I haven't had this experience.  This also is interesting, though. If I'm
headed down a bad path, it would be great to know early.

So if you think there's reason to believe it's a bad path, I'm interested in
hearing at least the best few of these reasons, as long as they do something
like one of these things:
- indicate that "good enough" might not be true for YANG, or 
- give a good hint for which alternate language would be significantly better, or
- give an understanding of problems the YANG choice has that other languages don't

Thanks and regards,
Jake