The issue was raised (again) regarding the fact that Printer MIB traps do
not include the hrDeviceIndex. Without the hrDeviceIndex in the trap,
there is no way to discriminate among multiple printers managed by a
single SNMP agent. We may need to add another varBind object for
hrDeviceIndex.
ISSUE: Who will submit the draft text for this new (and critical)
varbind object? (This was not discussed during the meeting??)
I had the action item to try to explain how an NMS could determine which
device caused a trap from the trap information without having to poll all
devices supported on the host that trapped. While the trap OID itself
(printerV2Alert) does not include the hrDeviceIndex, each of the varBinds do.
So each of the varBinds: prtAlertIndex, prtAlertSeverityLevel,
prtAlertGroup, prtAlertGroupIndex, prtAlertLocation, and prtAlertCode shall
contain the
hrDeviceIndex in them. So an NMS receiving the trap need only remove
the last arc from the OID for one of them, say the prtAlertIndex, to get
the next to last OID arc which contains the value for hrDeviceIndex
that corresponds to the device that generated the trap.
Do others agree?
If we do add another varBind to the list, we have the issue as to
whether we are forced to assign a new trap OID by SNMP and IETF rules
or can we keep the same value for printerV2Alert (and its V1 counter part)
which RFC 1759 specifies as:
{ mib-2 43 18 2 0 1 }?
I vaguely remember some discussion that we would need to assign a new
trap OID. So is it worth assigning a new trap OID?
Our implementors commented to me that it would have been good to include the
hrDeviceIndex as a varBind in RFC 1759, but now that they have the code
to break apart the varBind OIDs to find the hrDeviceIndex (and so should
everyone else, unless they all assume that the hrDeviceIndex = 1), it
doesn't help to have the hrDeviceIndex in the new RFC.
I suggest that we survey the implementors of software that accepts traps
and determine if they all are parsing the hrDeviceIndex to find which
device generated the trap.
In fact the test suite for RFC 1759 should include an implementation with
multiple devices, or at least one in which the hrDeviceIndex isn't 1.
If we agree (again) that we don't need to add hrDeviceIndex to the varBind
list, then I suggest that we add the following NOTE to the NOTIFICATION-TYPE
DESCRIPTION:
NOTE: While the trap OID (printerV2Alert) itself
does not include the hrDeviceIndex, each of the varBinds do.
So each of the varBinds: prtAlertIndex, prtAlertSeverityLevel,
prtAlertGroup, prtAlertGroupIndex, prtAlertLocation, and prtAlertCode shall
contain the
hrDeviceIndex in them. So an NMS receiving the trap need only remove
the last arc from the OID for one of the varBinds, say the prtAlertIndex,
to get the next to last OID arc which contains the value for hrDeviceIndex
that corresponds to the device that generated the trap.
Thanks,
Tom