Subject: Re: [eman] I-D Action: draft-ietf-eman-battery-mib-05.txt

From: Brad Schoening <[email-masked]>
Date: Thu, 12 Apr 2012 00:13:20 -0500

Juergen, Rolf, & Thomas,

I have reviewed the recently update to the draft Battery MIB and have the
below comments.  Most are simple syntax issues with a few issues of
substance around entPhysicalClass and unit declarations.

------------------

Sec 1 - Introduction
	"that provides means for"			-> suggest "that provides a means for"
	"Battery MIB module serves for"          -> suggest "Battery MIB module
provides for" instead
	"the Battery MIB allows to monitor"	-> suggest "allows us to monitor"

	"There is already instrumentation for monitoring battery status on many
battery-driven devicesŠ"
	
	This is a little hard to follow because you say 'already' and then
qualify it with 'many'.  Perhaps re-
	arrange this to 
	-->"Many battery-driven devices have existing instrumentation for
monitoring battery statusŠ"

"Not explicitly in scope of definitions in this document are very small
backup batteries'"	
Sec 3.1 MIB Module Structure
-->What "definition" is being referred to here?  The EMAN requirements?

	You state "The kind of entity in the entPhysicalTable of the Entity MIB
module is indicated by the
	value of the enumeration object entPhysicalClass.  Since there is no
value called 'battery' defined for
	this object, it is RECOMMENDED that for batteries the value of this
object is chosen to be
	powerSupply(6)."

	-> Why not "other(1)"?  It seems misleading to call a battery a power
supply as traditionally a
	power supply is also a transformer that performs AC/DC conversion.  If a
managed entity for powerSupply(6)
	already exists on a device, then this might negatively affect management
tools that look for and manage
	power supplies.

	batteryLowAlarmCharge
	batteryLowAlarmVoltage

	->  Is there a reason 'Alarm' is inserted in the middle between "low" and
"charge" and not at the
	beginning or end?  I think it would be more readable if it was
batteryLowChargeAlarm.  Same for
	High/LowAlarmTemperature.

Sec 3.2 Battery Technologies

	"Battery type distinguished primary (not-rechargeable) batteries from
secondary (rechargeable) batteries."

	-> this statement is correct, but it had worried me at first because the
terms primary/secondary are not that
commonly used.   I think a sentence or two to explain primary cells and
secondary cells might be helpful here.

	"massively used technologies are often replaced by successor technologies"
	-> massively is a bold word.  You could soften this by stating "widely
used technologiesŠ"

	"can be added to the IANA registry if new technologies get developedŠ"
	-> suggest "if new technologies are developed"

	-> The table with battery technology needs to be edited for case
consistency.  You have "Zinc-carbon" and
	"lithium-iron", and "Lithium ion".

Sec 4 Definitions

	batteryDesignVoltage OBJECT-TYPE
		SYNTAX		Unsigned32
		UNITS		"milllivolt"

	batteryDesignCapacity OBJECT-TYPE
		SYNTAX		Unsigned32
		UNITS		"milliampere hours"

	batteryMaxChargingCurrent
		SYNTAX		Unsigned32
		UNITS		"milliampere"

	-> For unit scale, the UPS-MIB uses 0.1 Amp DC.  I'm not sure which form
is preferred, milliamp or 0.01 Amp, so long as we are using the most
common syntax to represent scale.  Below are attributes from the UPS MIB

	upsBatteryVoltage OBJECT-TYPE
	SYNTAX     NonNegativeInteger
	UNITS      "0.1 Volt DC"

	upsBatteryCurrent OBJECT-TYPE
	SYNTAX     Integer32
	UNITS      "0.1 Amp DC"

	-> Also, should you clarify that the measured values are in DC?

	batteryActualCharge OBJECT-TYPE
		SYNTAX  Unsigned32
		UNITS "milliamphere hours"

	-> This would max-out at 4294 k-amp hours and might be best if it was an
Unsigned64 to provide greater headroom.

	"This notification can be generated when the actual temperatureŠ"

	-> Why 'actual'?  If its a measured temperature, it would be subject to
drift from actual.

Section 5  Security Considerations

	"older and less performant as required for stable operation"

	-> suggest "then required for"

	"this may on one side lead to a costly too early replacement of a
battery.  But it may also cause
	That too old or too weak batteries are used.  This may have the
consequence that a battery
	cannot long enough provide power."

	-> needs to be re-phrased

	"that have legitimate rights to indeed GET or SET"

	-> the 'indeed' needs to be re-phrased or just removed

Section 6.2  Battery Technology Registration

	"18 values for Š"

	-> Generally, you should not start a sentence with a number, use
"Eighteen values forŠ"

Section 9.2  Informative References
	[I-D.ietf-eman-framework]Š  Silver, L.
	[I-D.ietf-eman-energy-monitoring-mib] .. Silver, L.

	-> You've swapped the town I reside in for my name.  It should be
"Schoening, B."

Regards,

Brad Schoening
Little Silver, New Jersey

On 3/7/12 8:48 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the Energy Management Working
>Group of the IETF.
>
>	Title           : Definition of Managed Objects for Battery Monitoring
>	Author(s)       : Juergen Quittek
>                          Rolf Winter
>                          Thomas Dietz
>	Filename        : draft-ietf-eman-battery-mib-05.txt
>	Pages           : 30
>	Date            : 2012-03-07
>
>   This memo defines a portion of the Management Information Base (MIB)
>   for use with network management protocols in the Internet community.
>   In particular, it defines managed objects that provide information on
>   the status of batteries in managed devices.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-05.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>This Internet-Draft can be retrieved at:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-05.txt
>
>_______________________________________________
>eman mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eman