Subject: Resend: Re: PWG> ISSUE: Add hrDeviceIndex as a varBind to the Printer MIB? (fwd)

From: Steve Waldbusser <[email-masked]>
Date: Mon, 2 Dec 1996 12:00:32 -0800 (PST)

---------- Forwarded message ----------
Date: Mon, 2 Dec 1996 10:12:26 -0800 (PST)
From: Steve Waldbusser <[email-masked]>
To: Tom Hastings <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PWG> ISSUE: Add hrDeviceIndex as a varBind to the Printer MIB?

On Mon, 2 Dec 1996, Tom Hastings wrote:

> >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?

Yes, this is how we designed it in the original RFC.

Steve

---

From: Tom Hastings <[email-masked]>
Date: Tue, 3 Dec 1996 14:28:19 PST

Steve,

Our Internet Draft 00 just posted does add the hrDeviceIndex onto the 
end of the trap varBinds.  Is that ok?  

The draft also uses the same trap OID:  { mib-2 43 18 2 0 1 }
Is that ok?

Or should the document assign a new trap OID, say:  { mib-2 43 18 2 0 2 } 
so that NMS can distinguish between the two traps: 
the ones that they have to parse a varBind to determine the 
hrDeviceIndex and the ones that they can use the value of the new 
7th varBind parameter directly.

Or do you recommend that we keep the draft MIB the same as the proposed 
Printer MIB (RFC 1759) and not add hrDeviceIndex to the trap varBinds?  

If we do keep the draft MIB the same as the proposed MIB (by issuing
another Internet Draft), I strongly suggest that we add the following 
note to help implementors understand (since no one at the PWG meeting 
last month could explain what would be parsed and how).  Ok?  

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.

Do you have any suggestions on the text for such a note?

Thanks,
Tom