Re: [Taps] Potential alternatives to YANG

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

Hi Michael,

Responses inline with [JH].

On 2019-04-18, 04:56, "Scharf, Michael" <[e-mail]> wrote:
> > 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.

> 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