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

Hi Juergen,

Thanks for the explanation of the difference between "configuration data" and
"persistent configuration data".

>From your final statement...
> 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.

I take it that you would assert that the draft statement should read "SNMP MIB
modules creating and modifying configuration" leaving out the word "persistent"

Thanks,
Adrian

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email protected]]
> Sent: 28 February 2014 18:57
> To: Adrian Farrel
> Cc: 'Benoit Claise'; 'ops-area'
> Subject: Re: [OPS-AREA] 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/>