Re: [eman] Questions/Comments on EMAN MIBs

[Juergen Quittek <[e-mail]>]

Hi Brian,


Am 21.02.13 19:29 schrieb "Brian Hedstrom" unter
<[e-mail]>:

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

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


>
>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
>[e-mail]
> 
>
>
>
>
>
>_______________________________________________
>eman mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/eman