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

[Thomas Nadeau <[e-mail]>]

On Feb 12, 2014:10:18 AM, at 10:18 AM, Juergen Schoenwaelder <[e-mail]> wrote:

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

	(chair hat off)
	
	Power distribution networks are I guess a type of enterprise network
but there are definitely "wan" cases too such as the smart grid work I did 
a bit of at BT. In these cases you often have much tighter security constraints 
to prevent unwanted tampering or worse - disconnecting the power. *)

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

	That is a very good point. 

	--Tom



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