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

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Feb 2014 11:02:32 -0500

EMAN WG:

	The EMAN WG currently has three MIBs that are WG drafts:

	draft-ietf-eman-battery-mib-11	
	draft-ietf-eman-energy-aware-mib-14
	draft-ietf-eman-energy-monitoring-mib-08

	At present Benoit as AD, the Ops Directorate and MIB Doctors are preparing a statement to WGs that strongly recommends against MIBs with writable objects unless the working group has a strong consensus to do so. The current *draft* of the statement is listed here for your information:

The OPS area recommends the use of NETCONF/YANG standards for
configuration. IETF working groups are therefore encouraged to use
the NETCONF/YANG standards for configuration, specifically in new
charters. SNMP MIB modules modifying persistent configuration state 
should only be produced by working groups in cases of clear utility and 
overwhelming consensus to use SNMP write operations for configuration.

	In an effort to head off any potential snafus during the IESG review
of the three EMAN MIBs, I want to poll the WG for consensus on whether or not 
to make the current list of WG documents read-write or read-only. If there is 
not strong consensus to leave them read-write, Nevil and I will instruct the 
editors to edit the documents to remove writable objects.

	Please post comments on this matter by Friday, February 14, 2014 
at 9AM EDT.

	Tom
	EMAN WG Co-Chair

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 12 Feb 2014 09:35:42 +0000

Hi,

I believe that we need to look carefully what removing writeable objects means at this phase.  

Let us take a look at the writeable objects in draft-ietf-eman-battery-mib-11. There are seven objects with a MAX-ACCESS clause of read-write. 

One of them is batteryChargingAdminState and this is probably the only 'configuration'  object. It does not make too much sense to make it read-only, as there is a corresponding batteryChargingOperState  object. Basically making the MIB module read-only means giving up this functionality and taking out the object. 

The other six objects batteryAlarmLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature set thresholds for notifications. Making the MIB module read-only means that thresholds cannot be set, so there is no use for the objects, and no use for the respective notifications. 

What is the plan? Will the WG renounce to these functions? Is the remaining MIB module consistent enough to be worth making it a standard? If the functionality is still desired do we plan to create a YANG module instead? Will battery devices support NETCONF and YANG? 

Regards,

Dan

> -----Original Message-----
> From: eman [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> Sent: Tuesday, February 11, 2014 6:03 PM
> To: eman mailing list
> Subject: [eman] Read-Only or Read-Write EMAN MIBs
> 
> 
> 	EMAN WG:
> 
> 	At present Benoit as AD, the Ops Directorate and MIB Doctors are
> preparing a statement to WGs that strongly recommends against MIBs with
> writable objects unless the working group has a strong consensus to do so.
> The current *draft* of the statement is listed here for your information:
> 
> configuration. IETF working groups are therefore encouraged to use the
> NETCONF/YANG standards for configuration, specifically in new charters.
> SNMP MIB modules modifying persistent configuration state should only be
> produced by working groups in cases of clear utility and overwhelming
> consensus to use SNMP write operations for configuration.
> 
> of the three EMAN MIBs, I want to poll the WG for consensus on whether or
> not to make the current list of WG documents read-write or read-only. If
> there is not strong consensus to leave them read-write, Nevil and I will
> instruct the editors to edit the documents to remove writable objects.
> 
> 	Please post comments on this matter by Friday, February 14, 2014 at
> 9AM EDT.
> 
> 
> 	Tom
> 	EMAN WG Co-Chair
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Feb 2014 11:17:51 +0100

Hi,

if you keep the objects (and I think you should - new guidelines
should IMHO not impact almost complete work), I would appreciate if
the document is explicit what the persistency properties of these
objects are. A MIB doctor might ask that question anyway.

/js

On Wed, Feb 12, 2014 at 09:35:42AM +0000, Romascanu, Dan (Dan) wrote:
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 12 Feb 2014 13:53:24 +0000

Hi,

In a previous mail I expressed my opinion about removing the writable objects of draft-ietf-eman-battery-mib-11.

Here is my take on the other two documents.

draft-ietf-eman-energy-aware-mib-14 already has conformance clauses for read-only and read-write support. Folks should be aware that making the devices readable only means that the configuration objects in the MIB module which are about the reporting policies and domains will not be writeable via a standard interface. I have no operational experience with energy management to have an opinion if this makes sense or not. 

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. 

Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Feb 2014 15:50:08 +0100

> 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 strin…

Since the persistency of eoPowerEnableStatusNotification is not spelled
out, it remains unclear whether this object is configuration or not.

/js

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 12 Feb 2014 09:58:38 -0500

> 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 strin…
	
	(Speaking without my chair hat on)

	But those switches and any other writable objects, do fall under the concern being discussed which was that many/most operational environments prohibit devices from implementing SNMP writes; therefore, those objects, albeit relatively benign, will not be available either in many environments. 

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 12 Feb 2014 10:00:59 -0500

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

	--Tom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Feb 2014 16:18:57 +0100

> 	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

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 12 Feb 2014 10:25:59 -0500

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

> 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

>   the result is implementation-dependent.

	That is a very good point. 

	--Tom

---

From: Bruce Nordman <[email-masked]>
Date: Fri, 14 Feb 2014 00:07:24 -0800

Since EMAN is to be used for any type of energy-using
device - a vastly larger set than network equipment - I
think it premature to rule out using SNMP for writing
data to devices.  I don't think this undermines the principle
of not doing so for purposes of general network management.

--Bruce

On Tue, Feb 11, 2014 at 8:02 AM, Thomas Nadeau <[email-masked]>wrote:

> not

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov <http://nordman.lbl.gov>*
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Sat, 15 Feb 2014 03:57:47 +0000

Hi,

We have read-only implementations of the EMAN-MIB on Cisco platforms as a first step towards reporting.

Thanks
Mouli

EMAN WG:

Tom
EMAN WG Co-Chair

---

From: "David Prantl" <[email-masked]>
Date: Mon, 17 Feb 2014 09:42:45 +0100

Hi,

Currently the Cisco Energywise Manager/Joulex Energy Manager only has been
used with read-only implementations of the EMAN-MIB.

Thanks
Mouli

-----Original Message-----
From: eman [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Dienstag, 11. Februar 2014 17:03
To: eman mailing list
Subject: [eman] Read-Only or Read-Write EMAN MIBs

	EMAN WG:

The OPS area recommends the use of NETCONF/YANG standards for configuration.
IETF working groups are therefore encouraged to use the NETCONF/YANG
standards for configuration, specifically in new charters. SNMP MIB modules
modifying persistent configuration state should only be produced by working
groups in cases of clear utility and overwhelming consensus to use SNMP
write operations for configuration.

	Tom
	EMAN WG Co-Chair

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 17 Feb 2014 09:00:34 +0000

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? 

Thanks and Regards,

Dan

> From: eman [mailto:[email-masked]] On Behalf Of David Prantl
> Sent: Monday, February 17, 2014 10:43 AM
> To: 'Thomas Nadeau'; 'eman mailing list'
> Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs
> 
> Hi,
> 
> Currently the Cisco Energywise Manager/Joulex Energy Manager only has
> been used with read-only implementations of the EMAN-MIB.
> 
> Thanks
> Mouli
> 
> 
> configuration.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Feb 2014 10:10:27 +0100

> 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, batteryAlarmLo…

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.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 17 Feb 2014 10:05:50 +0000

Yes, this looks like a good strategy. 

Regards,

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Monday, February 17, 2014 11:10 AM
> To: Romascanu, Dan (Dan)
> Cc: David Prantl; 'Thomas Nadeau'; 'eman mailing list'
> > 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.
> 
> /js
> 
> --

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 17 Feb 2014 07:45:23 -0500

> On Feb 17, 2014, at 4:10 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

	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

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 19 Feb 2014 18:54:47 +0000

Responding  to Tom's request....

"""
"""

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:[email-masked]] 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

	--Tom