One issue I have had with Yang Models is the vendor not implementing NetConf RPC calls for everything in the model. It’s in the model, but there is no RPC call behind it. Shane
On Mar 24, 2025, at 3:46 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
On 23/03/25 20:33, Jeff McAdams via NANOG wrote:
How awesome would it be if we, as networking folk, could use the same tooling and technologies that all of the rest of the IT world uses to talk to our gear and systems and leverage all of the expertise that exists in other teams? We can't, though, but we insist on developing our own transports and tooling, on developing our data modeling languages, and on developing our own observability protocols. There isn't some other universal data model or meta-model out there,
On Sun, 2025-03-23 at 18:11 +0100, nanog--- via NANOG wrote: On 21/03/25 15:06, Jeff McAdams via NANOG wrote: that's better that we're obviously stupid not to use. They all suck in their own ways. YANG is no worse than any of the others. YANG is worse than the others, because there's a whole ecosystem of tooling that isn't YANG (or build around YANG) that the networking world has forgone using. OK, maybe it isn't that YANG itself is worse (although, I do think it is, but reasonable people could disagree), but the ecosystem of tooling around YANG is just pitiful compared to the tools and techniques that the rest of IT is using.
What tooling do you feel that is? I haven't encountered it yet.
We've got meta-models like JSON schemas (suck), XML DTDs (suck), XSD schemas (better than DTDs, but suck), protobufs (very limited), UML (what are you smoking?), MIBs (suck because everything has to fit OID tables. You don't get the full power of ASN.1).
At least YANG reasonably attempts to model the data itself instead of the serialization format. It has XML-isms, but very few that can't be transposed easily enough to a JSON serialization (sometimes the string representation of datatypes in constraints is problematic). This makes it better suited for its purpose than something like protobufs, MIBs, or XML schemas. It has an expressive constraint language, allowing for validation other than by trial and error.
Let me be clear, it's not about the data model, it's not about standardized MIBs or YANG models, or whatever. Let each vendor build their own model that fits their implementation, again, like the rest of the IT world does when building their systems that are running circles around the networking world in interoperability. Agree. Standard models are good but only if they work well. If they don't work well then don't use them. Working well on this device is more important than being identical on all devices, although both are important. The standard may be implemented as a compatibility layer over the non-standard model. Of course, YANG isn't a data model at all, it's a method of encoding data models. i.e. a meta-model, a model of models
REST isn't even a real protocol. It's an idea that your API should be built around state, rather than operations. Maybe in original theory. In practice is a set of practices and behaviors that the IT world is using to build amazing things. Yes, occasionally augmented by some other tooling/protocols/etc. What are the specific practices? I know some people treat it as a synonym for "an API that uses HTTP and JSON" but surely you have something more specific in mind. That is, ConfigurePort(1, {duplex=full, mtu=1500, stp=disabled}) rather than SetPortDuplex(1, full); SetPortMTU(1, 1500); STPDisablePort(1); NETCONF is REST. Whether NETCONF is REST or not isn't the point. You strongly hinted that we should be using REST instead of NETCONF, no? The point is that NETCONF (and YANG) is, effectively, only used in the networking world. To a rounding error, no SREs use it, no systems engineers use it, no storage engineers use it, no database engineers use it.... Well, they should. It's pretty cool. Remind me to incorporate it into my next project, possibly as a model for JSON files. My point is that networking as a whole is so insular, that we can't even, as a group by and large, see where IT has moved on with the techniques and tooling that they use, with the result that we're stuck 10 years in the past relative to their capabilities. Can you explain what these techniques, tooling and capabilities are? I haven't seen any concrete examples in this discussion. Apart from OpenAPI.
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HTEUZIRG...