Sometimes I wonder if we should just silently wrap every op mode command in sudo, at least those in the families other than show. It's hard to name a command that doesn't need sudo, and everyone (myself included!) has forgotten to add it at least once.

All sounds good to me.

As far as I remember, originally in our Quagga days, it was the case: nothing was advertised if it wasn't present in the RIB. So if you wanted to advertise e.g. 192.0.2.0/24 but had it split into /25's, you'd need both set protocols bgp ... network 192.0.2.0/24 and set protocols static route 192.0.2.0/24 blackhole.

I think I agree: at commit time, user's CLI edit level is irrelevant and should have no effect on the script behaviour.

Could you describe your "dream syntax" for it?
The op mode node.def's simply don't have a concept of value help in vyatta-cfg, only comp_help (<completionHelp> in XML terms).

We took other steps that allows us to take the image back to a manageable size, and this task lost its immediate relevance.

Good point! PR merged.

The runtime errors are fixed by the above commit.

I agree. If it works in a way that is consistent with what the command promises, let's use it.

Frankly, I can see why FRR doesn't want it to be modifiable at runtime. If you are decreasing the number, it would force a big routing table rebuild, and tracking whether the user increased or decreased it to decide if command should be allowed or not is more trouble than it's worth.

The original client-id has been cherry-picked into crux, but the vendor-class commands are not backportable since they rely on the new interface scripts.

Also in crux now.

Cherr-picked into crux.

I agree. Users should be able to change the port independently from the address.

Myself I'm in favor of maintaining a fork and asking people to install it. We can add a version check to the ./configure script to make sure it stops and tells the user what to do if the version is not patched.