Subject: [eman] New version of the battery MIB

From: Rolf Winter <[email-masked]>
Date: Thu, 11 Aug 2011 12:25:18 +0000

WG,

we have just posted another version of the battery MIB. This version:

- addresses the comments raised by Bill Mielke (thanks!)
- changes terms a little to either address comments received or to align with the Smart Battery Spec
- aligns with changes in the framework document
- includes some restructuring of the text
- includes the proposed text for re-arming the battery low notification as presented in the meeting
- adds the following open issue: 
   Shall we add managed objects and notifications that are based on the
   estimated time that the battery will be able to provide power (time-
   to-empty) or will need until it is fully charged (time-to-full).  In
   general this is useful and desired information.  However, this
   information is not reliable.  It is based on the assumption that the
   actual current will be continuous drawn from the battery or used to
   charge the battery.  Additionally, it is assumed that the battery
   chemistry works as expected.  Both may not be the case.
- updates the reference section

If you have any comments or further questions, please let us know.

Thanks,

The authors

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 11 Aug 2011 07:36:39 -0500

Hi Rolf,

Reply in line. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rolf Winter
Sent: Thursday, August 11, 2011 5:55 PM
To: eman mailing list
Subject: [eman] New version of the battery MIB

WG,

- addresses the comments raised by Bill Mielke (thanks!)
- changes terms a little to either address comments received or to align
with the Smart Battery Spec
- aligns with changes in the framework document

Mouli>>> Would the battery have a UUID ? There seems to be consensus on
a requirement for the use of UUID. 

- includes the proposed text for re-arming the battery low notification
as presented in the meeting

Thanks,

The authors

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014 

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: Rolf Winter <[email-masked]>
Date: Fri, 12 Aug 2011 07:33:44 +0000

Hi Mouli,

This is how Benoit earlier summarized the outcome regarding this:

"So, as discussed during the meeting, on based on this dicussion on the list,  the battery should be integrated to the framework, with its own UUID, with its own power state set/power state, and on the top of this, it should support the battery-mib."

I haven't seen any objections to his interpretation of the outcome of the discussion.

Does this answer your question?

Best,

Rolf

> From: Mouli Chandramouli (moulchan) [mailto:[email-masked]]
> Sent: Donnerstag, 11. August 2011 14:37
> To: Rolf Winter; eman mailing list
> Subject: RE: [eman] New version of the battery MIB
> 
> Hi Rolf,
> 
> Reply in line.
> 
> Thanks
> Mouli
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 12 Aug 2011 03:48:39 -0500

Hi Rolf,

Exactly. 

My question was more on - how does this revision of the battery mib
address this point of discussion and the conclusion. 

IMHO, it would be good to add some text, how this shall be handled. 

Thanks
Mouli

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Friday, August 12, 2011 1:04 PM
To: Mouli Chandramouli (moulchan); eman mailing list
Subject: RE: [eman] New version of the battery MIB

Hi Mouli,

"So, as discussed during the meeting, on based on this dicussion on the
list,  the battery should be integrated to the framework, with its own
UUID, with its own power state set/power state, and on the top of this,
it should support the battery-mib."

I haven't seen any objections to his interpretation of the outcome of
the discussion.

Best,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Fri, 12 Aug 2011 08:52:09 +0000

Hi Mouli,

there is a little bit of text in this direction (when you do a diff you'll easily spot it) but we will write more once there is a definitive conclusion on this issue.

Best,

Rolf

> Sent: Freitag, 12. August 2011 10:49

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 12 Aug 2011 21:05:46 -0700

Hi Mouli,

Maybe all we need is already contained in the document.

1. We have the managed object batteryIdentifier that contains the an ID 
assigned by the manufacturer and that is somehow stored with the battery.
It's syntax allows representing a UUID, but is not restricted to the 16 octet
length of a UUID as defined in RFC 4122.
If the manufacturer has given its battery a universally unique ID, it is in here.
However, it may have a different format than specified in RFC 4122.
Would it be a good idea recommending Battery manufacturers to use
the UUID defined in RFC 4122? 

2. I think we agreed that we will try to have the Entity MIB providing UUIDs.
Since the Battery MIB points to the Entity MIB (if present), it does not need 
its own managed object to store a UUID.
If there is no Entity MIB implementation present, then I would assume that
there is no need to model the battery as separate entity and hence it does
not need its own UUID.

Thanks,

    Juergen