On Thu, 20 Mar 2025 at 15:47, Mark Prosser via NANOG <nanog@lists.nanog.org> wrote:
Additionally, that static transform into JSON from XML results in some really horrendous json to work with. It is workable, but it's not fun. This only applies to state data, the json rendering of config info "show config ... | display json" is as you would expect. There is a config switch that purports to output "compact" json for state commands, but it generates (usually) invalid json (doesn't put lists into "[...]").
I've noticed this as well. When I'm working with the piped outputs, I typically prefer xml & then utilize `xmltodict` and `jsonata` to get something workable for my use case.
I think it's absolutely crucial to realise that the trade-off is between: 1) no formal serialised data 2) formal serialised data with format that you don't quite agree with As a programmer, it is very easy for me to choose which trade-off I want. To me having 100% coverage is important, and I'll gladly trade off on how subjectively well thought-out the data is. I think netconf and yang completely misunderstood what our problem is. Problem wasn't that as a programmer I couldn't work with MIB/ASN1, the problem was, MIB/ASN1 didn't have the coverage that I needed. Now we are in the same exact place, except instead of having poor coverage MIB we have poor coverage MIB and poor coverage YANG. So we pay more to be in the same position. Standard MIB and YANG are pipe dreams and the benefit is actually somewhat marginal. It is not hard ask when you add a new vendor, that you punch 1:1 mapping to old vendor - new vendor OIDs/YANGs. It's all formal data, you just figure out keys from old to new, and your whole stack works. You could ask the vendor to provide this mapping as part of procurement. AFAIK the only vendor who had 100% coverage in MIB was Nokia, because their internal provisioning system used that API. Any vendor who did this correctly to begin with, had Internal Representation of state in some proprietary format. Which they then programmatically transform to Config ASCII, enterprise MIB/YANG, and those are not pretty, but they always could offer you 100% coverage. There is no way to transform the internal state into any standard representation, it will never be a thing because it cannot be. There the problem continues, because we keep asking for the wrong thing. If vendors had always done what Nokia did, always have 100% coverage of Internal State to MIB, we would have all automated this decades ago. And you'd just have this mapping infra of OIDs to vendors for your provisioning needs. -- ++ytti