[NANOG] Re: The Network CLI -- Love it ? Hate it? Needed?

[Saku Ytti via NANOG <nanog () lists nanog org>]

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
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/V6HFP45UYXVB7Z7ZH4MICZ6DPFOXDCHX/