Re: configuration: writable MIB modules versus NETCONF/YANG modules - part 2

On Fri, Feb 28, 2014 at 06:04:53PM +0000, Adrian Farrel wrote:

> Anyway, is there any reason why the draft IESG statement text uses
> "configuration data" in all cases except "SNMP MIB modules creating
> and modifying persistent configuration"? Why "persistent" in this
> one case? Does it make any difference whether SNMP is used to write
> persistent or non-persistent configuration data?

For an NMS, it is crucial to know whether something is persistent
configuration or dynamic operational state. Yes, a router's forwarding
plane does not care where the forwarding table entry came from.
However, those who have to troubleshoot things very likely want to
know whether a forwarding entry is coming from persistent
configuration or whether it is the result of some operational state
picked up at runtime. Similarly, when an NMS makes change, it likes to
know whether the change persists or not. CLIs often make clear
distinctions between changes that are persistent and stuff that is
forgotton on the next reload.

For SNMP MIB modules, exposing the difference is somewhat complicated
since you need to deal with StorageType objects to express what is
persistent (well and even StorageType allows freedom so that the
management system still has to guess). A simple operation such as
"show the persistent configuration" or "show the configuration used at
next reload" that every CLI supports is really hard to do with SNMP.
In contrast, tweaking operational state at runtime of stuff that is
there already is fairly easy. But even then, it often remains unclear
whether a change persists or not. Note also that some SNMP tools tend
to generate sequences of SNMP set requests to make a conceptual
change. This (a) causes the generation of temporary state and (b)
leaves it open when changes are actually committed to stable
storage. This all rasies costs (on both the device and the NMS side)
and makes things brittle. SNMP really is IMHO horribly broken for
configuration management and attempts to fix it failed. This is long
known and also documented in RFC 3535.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>