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

Responding  to Tom's request....

"""
Also, it would be good to hear from folks about how many actual read-write implementations exist, as well as read-write deployments. I forgot to include that in my original note last week.
"""

Objective Observations:

Implementations....
We have a Cisco mib which is close to the mib here out for ~5 years

It is both read/write and mgt vendors such as SolarWinds and IBM Tivoli asked for our proprietary mib to have write ability to change the operational / power state of a device and to add context information when we design reviewed it with them. Our Cisco works Prime uses the write values of the mib for the same use cases. EnMS vendors such as Joulex, CA Ecometer use our proprietary mib with write access again for the same use cases.

The PWG (printer working group) which has defined the oper states for printers also includes writeable values.

Deployments...
Too large to count at this point (installed base of solarwinds, Tivoli, Cisco Prime). Just about every instance of our mgt apps have the RW capability. 

IMO :
-  The compliance should be RO with RW available
- The context information if not writeable would be a bit useless if the NMS could not write to the device. You'd never get deployment context only manufacturer context.
- Awkward to detect high power/energy use then not be able to change it

HTH
Jp

-----Original Message-----
From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas D. Nadeau
Sent: Monday, February 17, 2014 4:45 AM
To: Juergen Schoenwaelder
Cc: eman mailing list
Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs

> On Feb 17, 2014, at 4:10 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
>> On Mon, Feb 17, 2014 at 09:00:34AM +0000, Romascanu, Dan (Dan) wrote:
>> Hi David,
>> 
>> I have a question about the read-only implementation of draft-ietf-eman-battery-mib . There are six writeable objects in the MIB module batteryAlarmLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature which set thresholds for notifications. In a read-only implementation how are these objects set - using CLI instead and then the MIB objects are used to display the values set by CLI? Or you do not do notifications at all?
> 
> The batteryCompliance seems to allow both options. You are not 
> required to implement batteryAlarmThresholdsGroup. If you choose to do 
> so, you are not required to implement the objects read-write. Of 
> course, if you support threshold notifications and implement 
> read-only, the parameters must be set via some other mechanism.
> 
> It may make sense to make the threshold objects conditionally 
> mandatory to implement (at least read-only) if the 
> batteryNotificationsGroup is implemented so that management 
> applications can see the thresholds generating the notifications.

	This is generally speaking, the normal mode of operation though right?  Maybe the approach here is to go through and make sure all of the conformance statements conditionally require the read-write objects at least read-only?

	Also, it would be good to hear from folks about how many actual read-write implementations exist, as well as read-write deployments. I forgot to include that in my original note last week.

	--Tom

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

_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman