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 <[email protected]> wrote: > > On 23/03/25 20:33, Jeff McAdams via NANOG wrote: >>> On Sun, 2025-03-23 at 18:11 +0100, nanog--- via NANOG wrote: >>> On 21/03/25 15:06, 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, >>> 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/[email protected]/message/HTEUZIRGGU7OZHFSUXQ32ACTFKUZPM4R/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/7XUXYEJEAASK5GFU34L2FYSGSKTXIEHZ/
