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

> -----Original Message-----
> From: OPS-AREA [mailto:[email protected]] On Behalf Of Juergen
> Schoenwaelder
> 
> 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'.
> 

So here's where I have a problem with the statement.
People who have not been involved in the years-long debate in the OPS area
about what is configuration versus what is operational state (which is still
ongoing in the netmod list and now here) will have difficulty interpreting
the current statement because we do not clearly identify the distinction
between RW objects for "configuration" versus RW objects for relatively
simple things like setting a threshold, or turning off an interface.

Some argue that, since SET is not widely deployed, defining a RW object in a
MIB is a waste of resources. I disagree. Even though vendors might implement
an object RW, or only RO, the definition of the object is clearly specified.
This means the object, in RO form, is part of a standardized data model for
monitoring; in RW form, even if not used with SNMP SET, it becomes a
standardized *Information Model* for CLI implementers to follow (and
possibly other protocol implementers). So if a WG thinks a RW object is
potentially useful to monitor/manage their protocol, they at a minimum would
be standardizing an information model for that "knob". I think that is a
useful thing to do.

David Harrington
[email protected]
+1-603-828-1401