Subject: [eman] Questions/Comments on EMAN MIBs

From: Brian Hedstrom <[email-masked]>
Date: Thu, 21 Feb 2013 18:29:33 +0000

EMAN WG,
I have some comments/questions on the EMAN MIBs.
batteryEntry: There is only a batteryIndex for this table.  How do you correlate which battery you are querying with respect the the device in the network?  For example, if I query batteryType.5, what does 5 correlate to when I potentially have 5 million batteries in my network that I am monitoring.  Most of the other tables in the EMAN MIB set include the EntPhysicalIndex as a Table Index.

eoEnergyParametersTable: The indexing is confusing on this table.  The first object in the table, eoEnergyObjectIndex, is not an index to the table.  This is confusing alone since generally MIBs are constructing with the indexes listed first in the tables.  The second object in the table, eoEnergyParametersIndex, is listed as an index to the table, but does not have it's MAX-ACCESS listed as Not-Accessible.

eoPowerStateEnterReason: should this be a read-create object?  The table does not have a row-status object to support read-create for the table.

eoProxyID: This is read-only. I'M not clear on how this table is used. Should this table be a RowStatus read-create table to dynamically create Relationships?

eoEnergyParametersIntervalMode INTEGER, <-- Corrected line

Thanks,
Brian Hedstrom
Senior Architect, Business & Operational Support Systems
CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
Google+: brian.hedstrom
Skype IM: brian.hedstrom
[email-masked]<mailto:[email-masked]>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 22 Feb 2013 10:49:31 +0000

Hi Brian,

Am 21.02.13 19:29 schrieb "Brian Hedstrom" unter
<[email-masked]>:

>batteryEntry: There is only a batteryIndex for this table.  How do you
>correlate which battery you are querying with respect the the device in
>the network?  For example, if I query batteryType.5, what does 5
>correlate to
> when I potentially have 5 million batteries in my network that I am
>monitoring.  Most of the other tables in the EMAN MIB set include the
>EntPhysicalIndex as a Table Index.

We are working on what you ask for already concerning the Battery MIB
module, see below.

However, I do not get your point.  If you have 5 million batteries in your
network that you are monitoring, you will probably as well have five
million network interfaces or five million hard drives in your network.
And current management systems give you all what you need to distinguish
them well.  Obviously, there are sufficient means available to distinguish
line card 5 at host A from line card 5 at host B.

So what you are missing is not clear to me at all.

Anyway, the integration with the entity MIB is the only mayor remaining
open issue for the Battery MIB module.  We are revising the Entity MIB v3
in the eman WG and will come up with Entity MIB v4 soon, see
http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/  With this in
place we will use it also in the Battery MIB module.

>eoEnergyParametersTable: The indexing is confusing on this table.  The
>first object in the table, eoEnergyObjectIndex, is not an index to the
>table.  This is confusing alone since generally
> MIBs are constructing with the indexes listed first in the tables.  The
>second object in the table, eoEnergyParametersIndex, is listed as an
>index to the table, but does not have it's MAX-ACCESS listed as
>Not-Accessible.

Thank you for pointing out these two issues.  Please note that we are
currently focussing on the eman framework.  The MIB modules may undergo a
significant revisions after the framework is agreed.

Coming back to your points:  Yes , I agree that
1. The eoEnergyObjectIndex is missign as first index in the INDEX
statement of object eoEnergyParametersEntry
2. The MAX-ACCESS clauses of objects eoEnergyObjectIndex and
eoEnergyParametersIndex should have the value "not-accessible".  There are
rare cases where index values can have other MAX-ACCESS values, here we do
not have such a case.

>eoPowerStateEnterReason: should this be a read-create object?  The table
>does not have a row-status object to support read-create for the table.

I fully agree.  Thew value of this MAX-ACCESS clause must be either
read-write or read-only.

>eoProxyID: This is read-only. I'M not clear on how this table is used.
>Should this table be a RowStatus read-create table to dynamically create
>Relationships?

I see no need for having this object being read-only.  Probably
not-accessible would be OK.

>eoEnergyParametersIntervalMode INTEGER, <-- Corrected line

Thank you again.  Yes, this needs to be fixed in object
EoEnergyParametersEntry.

Best regards,
    Juergen

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

---

From: Brian Hedstrom <[email-masked]>
Date: Fri, 22 Feb 2013 16:00:08 +0000

Are you thinking about modeling a Battery like a Sensor?

entPhySensorTable OBJECT-TYPE
    SYNTAX        SEQUENCE OF EntPhySensorEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
            "This table contains one row per physical sensor represented
            by an associated row in the entPhysicalTable."
    ::= { entitySensorObjects 1 }
entPhySensorEntry OBJECT-TYPE
    SYNTAX        EntPhySensorEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
            "Information about a particular physical sensor.
            An entry in this table describes the present reading of a
            sensor, the measurement units and scale, and sensor
            operational status.
            Entries are created in this table by the agent.  An entry
            for each physical sensor SHOULD be created at the same time
            as the associated entPhysicalEntry.  An entry SHOULD be
            destroyed if the associated entPhysicalEntry is destroyed."
    INDEX  { entPhysicalIndex }    -- SPARSE-AUGMENTS
    ::= { entPhySensorTable 1 }

Brian Hedstrom

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Mon, 25 Feb 2013 11:17:08 +0000

Hello Brian,

Replies inline. 

Thanks
Mouli 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Hedstrom
Sent: Friday, February 22, 2013 12:00 AM
To: [email-masked]
Subject: [eman] Questions/Comments on EMAN MIBs

EMAN WG,

eoEnergyParametersTable: The indexing is confusing on this table.  The first object in the table, eoEnergyObjectIndex, is not an index to the table.  This is confusing alone since generally MIBs are constructing with the indexes listed first in the tables.  The second object in the table, eoEnergyParametersIndex, is listed as an index to the table, but does not have it's MAX-ACCESS listed as Not-Accessible.
[ycm] eoParametersIndex was introduced based on feedback from the WG http://www.ietf.org/mail-archive/web/eman/current/msg01378.html
[ycm] on the need for collection of energy measurement using multiple windowing schemes. 
[ycm] With this indexing, for the same energy object with the same eoEnergyObjectIndex , it is possible to have two different eoEnergyParametersIndex                 
[ycm] for each eoEnergyParametersIndex  it is possible to have a specific windowing mechanism (total, or sliding, ...) for energy measurement collection. 
[ycm] I believe it is permissible to have to index of the table is accessible. 

eoPowerStateEnterReason: should this be a read-create object?  The table does not have a row-status object to support read-create for the table 
[ycm]  Yes, the MAX-ACCESS for this object can be read-write with the ownetstring syntax.   

eoEnergyParametersIntervalMode INTEGER, <-- Corrected line
[ycm] Currently, it is defined as eoEnergyParametersIntervalMode     Integer32, 
[ycm] and we shall update in the definition.  

Thanks,

Brian Hedstrom
Senior Architect, Business & Operational Support Systems CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
Google+: brian.hedstrom
Skype IM: brian.hedstrom
[email-masked]

---

From: Brian Hedstrom <[email-masked]>
Date: Mon, 25 Feb 2013 16:48:52 +0000

For the eoEnergyParametersTable, why not create a two index table: first
index being the entPhysicalIndex (same index as the eoPowerTable), second
index being the eoEnergyParametersIndex with a MAX-ACCESS of
Not-Accessible.  How many eoEnergyParametersIndex values can be supported
per entPhysicalIndex?

Thanks,
Brian Hedstrom

On 2/25/13 4:17 AM, "Mouli Chandramouli (moulchan)" <[email-masked]>
wrote:

>table.  This is confusing alone since generally MIBs are constructing
>with the indexes listed first in the tables.  The second object in the
>table, eoEnergyParametersIndex, is listed as an index to the table, but
>does not have it's MAX-ACCESS listed as Not-Accessible.
>[ycm] eoParametersIndex was introduced based on feedback from the WG
>http://www.ietf.org/mail-archive/web/eman/current/msg01378.html
>[ycm] With this indexing, for the same energy object with the same
>eoEnergyObjectIndex , it is possible to have two different
>eoEnergyParametersIndex
>[ycm] for each eoEnergyParametersIndex  it is possible to have a specific
>windowing mechanism (total, or sliding, ...) for energy measurement
>collection. 
>does not have a row-status object to support read-create for the table