PWG> ISSUE: Add hrDeviceIndex as a varBind to the Printer MIB?

PWG> ISSUE: Add hrDeviceIndex as a varBind to the Printer MIB?

PWG> ISSUE: Add hrDeviceIndex as a varBind to the Printer MIB?

Randy Turner rturner at sharplabs.com
Mon Dec 2 13:55:23 EST 1996


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




More information about the Pwg mailing list