Hi Michael, Responses inline with [JH].
On 2019-04-18, 04:56, "Scharf, Michael" <[email protected]> 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
