Tom Hastings wrote:
>
See my comments below, (not prefaced with a '>')
Randy
> >From the minutes of the New Orleans meeting:
>> 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?
I will check on this issue with Steve Waldbusser, I've got a whole list
of
stuff to talk with him about. I will hit the mailing list with the
responses
I get.
>> 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.
My gut instinct here tells me that 10 wrongs don't make a right, at
least
from a purely technical perspective. Just 'cause
we have code in place to handle an oversight shouldn't dictate our
future
decision making, after all it wasn't even a "draft" standard document. I
think
these are the kind of changes that a proposed-to-draft "wringing out"
should
seek to correct.
I will find out whether or not a new trap OID will have to be defined.
This
point will probably strongly influence which way we go on this
particular
point.
Randy
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com