Actually scratch that. I think we need to disambiguate what we mean 'first'. Like are you saying, YANG is earlier in Junos stack, than XML? Because I don't actually know what is the earliest form of data description in Junos. I assume C struct, but I have low confidence. Arista had some proprietary language (that they went to court with, as co-founder claimed IP rights) that compiles to C++, and I assume for Arista the earliest form of data is in this proprietary programming language? Which they could then possibly translate into YANG statically. But whatever it is, it would seem absolutely bizarre to choose anything where you don't control it completely. I don't know if Arista is still using that proprietary language, but I think it's absolutely brilliant and everyone who is going to have to support some program with large teams over decades should probably fork a programming language and compile into that target but control the language itself. So there are more abstractions and more places to address commonly occurring problems than hoping that people just don't make those mistakes. To me it is easy to understand how much benefit you can get, if you control the language you write in. Because every language, be it C++ or rust, has to support everything, so there are very few assumptions you can make, which makes the language more dangerous, tedious to write and bug prone. But if you know the application the language is going to be used for, you can make assumptions which will greatly help people writing safer and less buggy code. On Fri, 21 Mar 2025 at 18:13, Saku Ytti <saku@ytti.fi> wrote:
Junos absolutely isn't YANG model first, it is absolutely the same XML it's always been.
But which can be statically translated to anything else, as long as it's not standard.
I'm highly sceptical if anyone anywhere would decide to use anything standard for their internal representation and yield flexibility and control away, seems very inefficient and ends up with having to solve problems in the wrong place, because you can't change the internal format arbitrarily upon new problems that are best addressed by changes to the internal representation.
On Fri, 21 Mar 2025 at 17:13, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 21 Mar 2025, Saku Ytti wrote:
100% on board data-first/model-first internal representation (I think Junos, SROS, maybe others today?) 0% on board for standard models
Juniper (JunOS), Nokia (SROS) and Cisco (XR) are all YANG-model-first with proprietary models needed to do anything in the configuration engine, so their proprietary models are feature complete from a configuration pov.
I've run into others as well, for instance the ones made using Conf-D.
When discussing translation, question is what to translate to/from. The only way would be to create a standard model, which is exactly what's being done in multiple SDOs, for instance openconfig and ietf. As you say, they'll always be a subset, but if you can get by with openconfig for some of the functionality then devices supporting the openconfig model from multiple vendors can be configured for that subset using a single model instead of using the proprietary models.
-- Mikael Abrahamsson email: swmike@swm.pp.se
-- ++ytti
-- ++ytti