Re: [eman] Read-Only or Read-Write EMAN MIBs

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Feb 12, 2014 at 10:00:59AM -0500, Thomas Nadeau wrote:
> 
> On Feb 12, 2014:9:50 AM, at 9:50 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> > On Wed, Feb 12, 2014 at 01:53:24PM +0000, Romascanu, Dan (Dan) wrote:
> > 
> >> draft-ietf-eman-energy-monitoring-mib-08 has two writable objects. I do not understand well enough eoPowerStateEnterReason, in general I am no fan of objects that pass information by writable strings, so I do not have a clear opinion if it makes sense to make this object read-only or take it out. The second object eoPowerEnableStatusNotification is a switch that activates and de-activates notifications. Such MIB objects are not really configuration objects for the protocol or device, they rather configure the mode of work of the agents. I believe they can be left writable. 
> > 
> > Since the persistency of eoPowerEnableStatusNotification is not spelled
> > out, it remains unclear whether this object is configuration or not.
> 
> 	(Without my chair hat on)
> 
> 	Differentiating between persistent configuration or non-persistent is not going to matter if SNMP writes are operationally disabled, are they?
> 

Frankly, the fact that ISPs do not SNMP write does not mean SNMP
writes do not exist. Read the security horror stories about SCADA
networks.  SNMP has a significant share there and perhaps we would
wish things are not writable. ;-) My understanding is that the EMAN
work targets deployments most likely in enterprise networks. And I
think it is also bad style to cast a new policy (which is BTW not set
in stone yet either) and to tell WGs that have been working on
something for years to suddenly change their documents.

The WG needs to decide. If there is concensus to get rid of writable
objects, fine. My only take is that if you have writable objects, you
need to spell out the persistency propoerties.

RFC 4181 page 20:

   For read-write objects (other than columns in read-create tables that
   have well-defined persistence properties), it is RECOMMENDED that the
   DESCRIPTION clause specify what happens to the value after an agent
   reboot.  Among the possibilities are that the value remains
   unchanged, that it reverts to a well-defined default value, or that
   the result is implementation-dependent.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>