Harry Lewis has made an excellent suggestion on how to resolve the
issues with traps. It is unfortunate though that it is too late to
use this suggestion to "fix" the Printer MIB, if we discover that
changes are required. But I do believe that it will be beneficial to
follow Harry's suggestion, even though we do not intend to change
the MIB.
I do not believe that an interoperability test is needed in this
area. We do not have to prove that traps work or that every vendor
that supports traps has implemented them as they intended. It is
up to each vendor to verify their design.
We do need to verify that the information presented in the trap PDU
fields is consistent and is as defined in the SNMP documents. I
agree with Harry that the SNMP RFCs are not very clear in this area
and would guess that we will find differences in the implementations.
Harry identified the three fields of a v1 trap PDU that must be
examined.
What about v2 traps? Are there any v2 trap implementations?
The three v1 fields Harry highlighted are:
1. ENTERPRISE - I can not find a good definition of what this field
is to contain. To the best of my knowledge this should be
sysObjectId unless it is an "enterprise-specific" trap. For the
latter case this value is as specified by the ENTERPRISE entry
of the trap definition.
2. SPECIFIC-TRAP - My guess is this should be the value of
printerAlert (i.e. 1).
3. VARIABLE-BINDINGS - In this case what should be presented is
clearly defined, especially in light of the recent effort on
the "Top 25 Alert Conditions". Harry's questions need to be
answered. "Is everyone sending VarBinds? Are they mandatory?
Do we all send the same stuff?"
I propose that all participants of the interoperability test plus
anyone else who is implementing the Printer MIB submit a response to
the above. This data can be reviewed in a teleconference or we could
allocate an hour in the San Diego meeting.
Any comments?
Ron Bergman
Dataproducts Corp.