RE: Welcome to the "Libsmi" mailing list
Hi,
I need a clarification on the following.
1. When I went throught parser, I found all the INTEGER based types Counter, Gauge, TimeTicks are assigned a value of SMI_BASETYPE_UNSIGNED32. Is there any specific reason for not defining a new type for the Integer based APPLICATION types?
2. Having different types may help the developers while sending the traps. I feel it is inappropriate to send the Trap containing Gauge object with ASN_INTEGER(0x02) tag value.
3. Another thing, does the SNMP Manager will be really bothered about the mismatch of the object type defined in a MIB from whatever he get it from SNMP TRAP?
Can somebody help me out regarding this?
Your help will be greatly appreciated.
Thanks Mahesh.
HI,
See comments inline below...
On Thu, 29 Jan 2004, Kurapati M-G19456 wrote:
Hi,
I need a clarification on the following.
- When I went throught parser, I found all the INTEGER based types Counter, Gauge, TimeTicks are assigned a value of SMI_BASETYPE_UNSIGNED32. Is there any specific reason for not defining a new type for the Integer based APPLICATION types?
It is appropriate that these have a base type of UNSIGNED, because they are all unsigned, and NOT signed integers. And note, your statement "... all INTEGER based types..." is not correct. Types INTEGER and Integer32 are not assigned a base type of unsigned32!
- Having different types may help the developers while sending the traps. I feel it is inappropriate to send the Trap containing Gauge object with ASN_INTEGER(0x02) tag value.
It is a mistake in design to return values with the incorrect data type. That is, it is a BUG (design flaw) to not follow the MIB specification!
- Another thing, does the SNMP Manager will be really bothered about the mismatch of the object type defined in a MIB from whatever he get it from SNMP TRAP?
When a program was a design flaw in it, and it interacts with another program, it is up to the other program (such as the manager) to decide how to cope with the design flaw. Sometimes it is not too much additional work, and where there is no ambiguity, then support mey be added.
Regards, /david t. perkins
David T. Perkins wrote:
On Thu, 29 Jan 2004, Kurapati M-G19456 wrote:
I need a clarification on the following.
- When I went throught parser, I found all the INTEGER based types Counter, Gauge, TimeTicks are assigned a value of SMI_BASETYPE_UNSIGNED32. Is there any specific reason for not defining a new type for the Integer based APPLICATION types?
It is appropriate that these have a base type of UNSIGNED, because they are all unsigned, and NOT signed integers. And note, your statement "... all INTEGER based types..." is not correct. Types INTEGER and Integer32 are not assigned a base type of unsigned32!
- Having different types may help the developers while sending the
traps. I feel it is inappropriate to send the Trap containing Gauge object with ASN_INTEGER(0x02) tag value.
It is a mistake in design to return values with the incorrect data type. That is, it is a BUG (design flaw) to not follow the MIB specification!
- Another thing, does the SNMP Manager will be really bothered about
the mismatch of the object type defined in a MIB from whatever he get it from SNMP TRAP?
When a program was a design flaw in it, and it interacts with another program, it is up to the other program (such as the manager) to decide how to cope with the design flaw. Sometimes it is not too much additional work, and where there is no ambiguity, then support mey be added.
I just like to add some information on the history of libsmi: The library started as part of the implementation work towards a "cleaner" "SMIng". Part of the new language is a streamlined set of base types, i.e., based on representable value ranges, not stuck to the "strange" SNMP base type system that is based on semantics.
If you intend to use libsmi to retrieve supposed SNMP types for given object types, you have to implement a mapping like it is also done by the SMIv1/v2 output driver in tools/dump-smi.c.
participants (3)
-
David T. Perkins -
Frank Strauß -
Kurapati M-G19456