Subject: [eman] NOTIFICATION for battery removal

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Mar 2013 14:04:56 -0400

Hi,

Regarding the Online Insertion and Removal NOTIFICATION-TYPE for battery 
removal, here is what I had in mind:

cefcFRUInsertedNOTIFICATION-TYPE
     OBJECTS          { entPhysicalContainedIn }
     STATUS           current
     DESCRIPTION         "The cecfFRUInserted notification indicates that a FRU was
         inserted. The varbind for this notification indicates the
         entPhysicalIndex of the inserted FRU, and the entPhysicalIndex
         of the FRU's container.
"
    ::= { cefcMIBNotifications 3 }

cefcFRURemovedNOTIFICATION-TYPE
     OBJECTS          { entPhysicalContainedIn }
     STATUS           current
     DESCRIPTION         "The cefcFRURemoved notification indicates that a FRU was
         removed. The varbind for this notification indicates the
         entPhysicalIndex of the removed FRU, and the entPhysicalIndex
         of the FRU's container.
"
    ::= { cefcMIBNotifications 4 }

Unfortunately, this is a Cisco specific MIB: CISCO-ENTITY-FRU-CONTROL-MIB
http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-ENTITY-FRU-CONTROL-MIB

I'm not aware of an IETF MIB module supporting this.
I would be happy to stand corrected. That would mean that this 
notification would not only be for batteries, but also for power supplies.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Mar 2013 19:12:59 +0100

On Mon, Mar 11, 2013 at 02:04:56PM -0400, Benoit Claise wrote:
> Hi,
> 
> Regarding the Online Insertion and Removal NOTIFICATION-TYPE for
> battery removal, here is what I had in mind:
> 
 
The ENTITY-MIB, as far as I understand it, only has a generic
"something changed" notification (called entConfigChange) and as such
it expects that the management application after receiving the
notification investigates what has happened by reading through the
data model.

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

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 11 Mar 2013 21:18:51 +0000

Here's a reference to manufacturer Mib for similar notion on power supply change

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094aa0.shtml

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Mar 11, 2013, at 2:13 PM, "Juergen Schoenwaelder" <[email-masked]> wrote:

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

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 12 Mar 2013 05:51:49 +0000

Hi Benoit,

We have in the monitoring mib 

eoPowerStateChange NOTIFICATION-TYPE 
            OBJECTS       {eoPowerAdminState, eoPowerOperState, 
        eoPowerStateEnterReason} 
            STATUS        current 
            DESCRIPTION 
                "The SNMP entity generates the eoPowerStateChange when 
                the value(s) of eoPowerAdminState or eoPowerOperState, 
               in the context of the Power State Set, have changed for 
               the Energy Object represented by the entPhysicalIndex." 
           ::= { energyObjectMibNotifs 1 } 

Which would generate notifications, when the entity is power state is changed;  
Shutting the line card (is a power state change)  and removing the line card is sort of FRU type action. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise (bclaise)
Sent: Monday, March 11, 2013 11:35 PM
To: eman mailing list
Subject: [eman] NOTIFICATION for battery removal

Hi,

Regarding the Online Insertion and Removal NOTIFICATION-TYPE for battery removal, here is what I had in mind:

cefcFRUInserted NOTIFICATION-TYPE

cefcFRURemoved NOTIFICATION-TYPE
    OBJECTS         { entPhysicalContainedIn }
    STATUS          current
    DESCRIPTION        "The cefcFRURemoved notification indicates that a FRU was
        removed. The varbind for this notification indicates the
        entPhysicalIndex of the removed FRU, and the entPhysicalIndex
        of the FRU's container.
"
   ::= { cefcMIBNotifications 4 }
Unfortunately, this is a Cisco specific MIB: CISCO-ENTITY-FRU-CONTROL-MIB http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-ENTITY-FRU-CONTROL-MIB

I'm not aware of an IETF MIB module supporting this.
I would be happy to stand corrected. That would mean that this notification would not only be for batteries, but also for power supplies.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 12 Mar 2013 08:45:58 -0400

Hi Mouli,
> Shutting the line card (is a power state change)  and removing the line card is sort of FRU type action.
The issue that the cefcFRURemoved notifcation solves is to understand if 
your secondary power supply is gone.
There is nothing worse that _thinking _that you have high availability 
because you doubled the components, but, for whatever reason, that 
secondary component is not present any longer.

Regards, Benoit

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 12 Mar 2013 09:18:54 -0400

As I understand Mouli's point, components (like a battery)
can have a power state distinct from the power state of
the entire device.  Then, assuming we can generate a
notification for change of power state, then removing
the battery would do this assuming the battery removal
caused a power state change.  This could be a special
power state set for the battery, or a convention such
as that "off" for a battery meant that it was not present.
Such an approach seems simple.  Any reason this would
not work?

--Bruce

On Tue, Mar 12, 2013 at 8:45 AM, Benoit Claise <[email-masked]> wrote:

> There is nothing worse that *thinking *that you have high availability
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf Of Benoit Claise (bclaise)

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