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

On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote:
> 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"

There are different terminologies around and depending on the one used
I may agree or not. I definitely agree with "SNMP MIB modules creating
and modifying persistent configuration" but that is likely not what
you want to hear. ;-)

In the NETCONF world, configuration data is pretty much synonymous
with what I think you call persistent configuration. (The term
'persistent' does never appear in RFC 3535 but then RFC 3535
distinguishes between 'configuration data', operational state data,
and statistics. RFC 6244 says (section 4.3.2):

   o  Configuration data is the set of writable data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

This kind of implies that the configuration data is persistent since it
needs to be there when the device re-initializes.

   o  Operational state data is a set of data that has been obtained by
      the system at runtime and influences the system's behavior similar
      to configuration data.  In contrast to configuration data,
      operational state is transient and modified by interactions with
      internal components or other systems via specialized protocols.

This means that routing protocols or dhcp or even things like i2rs
simply mess around with operational state.

   o  Statistical data is the set of read-only data created by a system
      itself.  It describes the performance of the system and its
      components.

Given this terminology, I think what you call non-persistent
configuration is operational state data. For relatively simple things
that mess around with operational state (setting a threshold, turning
off an interface), SNMP's peek and poke model can work. For more
complex things, I personally would not recommend it but then I must
also note that there is no well established better generic solution
available in the IETF. Hence I believe it is right thing to limit
the statement to 'persistent configuration'.

/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/>