RE: [libsmi] esoteric error level
-----Original Message----- From: Frank Strauss
-- snip --
Another idea that came to my mind, is to add a much more verbose description to errors, since for errors like "index element `%s::%s' of row `%s' should but cannot have a size restriction" I would wonder if people get this error and do NOT ask what it means. :-)
If you could persuade Cisco, HP, IBM, Intel, etc. to put range restrictions in MIBs I might stop suppressing that warning.
Are some of the warnings not relevant to SMIv1 MIBs, or SMIv2 ones converted to SMIv2 by, say, smidump?
While we're here, what is the correct way to do these (taken from INTELCORPORATIONBASEBOARD-MIB which is SMIv1):
1) DmiInteger64X ::= INTEGER (-18446744073709551615..18446744073709551615)
./INTELCORPORATIONBASEBOARD-MIB:20: {} number `-18446744073709551615' is out of SMIv1/SMIv2 signed number range
Whether those values are sensible is irrelevant. They will not fit in 64 bits.
2) DmiComponentIndex ::= INTEGER
eComponentid OBJECT-TYPE SYNTAX SComponentid ACCESS not-accessible STATUS mandatory DESCRIPTION "" INDEX {DmiComponentIndex} ::= {tComponentid 1}
./INTELCORPORATIONBASEBOARD-MIB:57: {bad-identifier-case} `DmiComponentIndex' sh ould start with a lower case letter
The other way I've seen this done would use INTEGER instead of DmiComponentIndex as the index, and that causes most of the same errors.
Regards, Andrew Hood A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable. -- Leslie Lamport, as quoted in CACM, June 1992
Hi!
Another idea that came to my mind, is to add a much more verbose description to errors, since for errors like "index element `%s::%s' of row `%s' should but cannot have a size restriction" I would wonder if people get this error and do NOT ask what it means. :-)
AH> If you could persuade Cisco, HP, IBM, Intel, etc. to put range AH> restrictions in MIBs I might stop suppressing that warning.
??? I am missing context.
AH> Are some of the warnings not relevant to SMIv1 MIBs, or SMIv2 ones AH> converted to SMIv2 by, say, smidump?
??? Which warnings? Why SMIv2->SMIv2 conversion? What do you mean by converting warnings by smidump?
AH> While we're here, what is the correct way to do these (taken from AH> INTELCORPORATIONBASEBOARD-MIB which is SMIv1): [...]
"Here" is not the right place to discuss general SMI questions. (Both cases, (1) and (2), are simply illegal in SMIv1 and SMIv2. There is nothing more to say about such broken "MIBs".)
-frank
HOOD, Andy writes:
Another idea that came to my mind, is to add a much more verbose description to errors, since for errors like "index element `%s::%s' of row `%s' should but cannot have a size restriction" I would wonder if people get this error and do NOT ask what it means. :-)
Andy> If you could persuade Cisco, HP, IBM, Intel, etc. to put range Andy> restrictions in MIBs I might stop suppressing that warning.
You can not put a size constraints on OIDs and this is why the warning quoted above sounds so esoteric.
Andy> Are some of the warnings not relevant to SMIv1 MIBs, or SMIv2 Andy> ones converted to SMIv2 by, say, smidump?
It depends. ;-)
Andy> While we're here, what is the correct way to do these (taken Andy> from INTELCORPORATIONBASEBOARD-MIB which is SMIv1):
[...]
I believe (and libsmi implements it that way) that you can not ship 64 bit INTEGER in SNMPv1 or that you can define 64 bit INTEGER data types in SMIv1. (Although people sometimes argue about this.)
Andy> The other way I've seen this done would use INTEGER instead of Andy> DmiComponentIndex as the index, and that causes most of the same Andy> errors.
/js
participants (3)
-
Frank Strauss -
HOOD, Andy -
Juergen Schoenwaelder