Subject: Re: Alarm #38, #43 - trap/notification varbind and timestamps

From: Randy Presuhn <[email-masked]>
Date: Tue, 18 Jun 2002 17:53:44 -0700 (PDT)

Hi -

> Date: Tue, 18 Jun 2002 14:42:34 +0200
> From: David Partain <[email-masked]>
> Subject: Re: Alarm #38, #43 - trap/notification varbind and timestamps
> In-reply-to: <00ee01c212fe$04af84c0$0301a8c0@tom3>
> To: [email-masked]
> Reply-To: [email-masked]
> Message-id: <[email-masked]>
> User-Agent: KMail/1.4.1
> References: <00ee01c212fe$04af84c0$0301a8c0@tom3>
> List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com>
> 
> Hi,
> 
> On Thursday 13 June 2002 19.14, Tom Petch wrote:
> > I believe the same index should retrieve the same value, regardless of
> > v1 or v2 ie 1 for sysUpTime, 2 for SNMPTrapOID etc.  It is simple., it
> > is logical.  But I am not clear from the text if that is an option you
> > are offering me  !
> 
> There is no varbind holding sysUpTime.0 or SNMPTrapOID in
> an SNMPv1 trap.  They are embedded in the message wrapper.
> As such, what you are asking for is not possible.
> 
> Since the first two VarBinds in a v2c/v3 trap/inform somewhat
> approximate information that's in the message wrapper for
> SNMPv1 traps, I thought Sharon's proposed text was just fine
> (I removed the "real" from "real varbinds" since I don't know
> how to send a "fake" varbind).
> 
> That is:
> 
>  "For SNMPv1 traps, a 1 indicates the first varbind. For
>  v2Traps and Informs, a 1 indicates the first varbind after
>  the required varbinds of sysUptime and SNMPTrapOID."
...

The same logic leads me, as a technical contributor, down a
very different path.

In order to avoid losing information and to maintain the
valuable distinction between the notification and the active
alarm's time stamps, I would suggest that we follow the RFC 2576
rules (section 3.1) so that everything is represented as though
it had arrived in RFC 1905 format.  I think this is ultimately
simpler than introducing a new set of rules peculiar to this
MIB to treat everything as though it were SNMPv1.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Jun 2002 08:44:18 +0200

>>>>> Randy Presuhn writes:

Randy> In order to avoid losing information and to maintain the
Randy> valuable distinction between the notification and the active
Randy> alarm's time stamps, I would suggest that we follow the RFC
Randy> 2576 rules (section 3.1) so that everything is represented as
Randy> though it had arrived in RFC 1905 format.  I think this is
Randy> ultimately simpler than introducing a new set of rules peculiar
Randy> to this MIB to treat everything as though it were SNMPv1.

I agree.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

---

From: David Partain <[email-masked]>
Date: Wed, 19 Jun 2002 09:12:53 +0200

Hi all,

> MIB to treat everything as though it were SNMPv1.

That's absolutely fine with me.  In that case, the DESCRIPTION
for alarmModelVarbindIndex needs to explain this.  The issue
remains that if that holds a value of 2, and that's going to
refer to the trap OID even if the incoming notification is a v1
trap, then there must be some information in this description
that states that.  Otherwise, I think there's a strong risk for
confusion.

How about this as a replacement for the second paragraph of
the DESCRIPTION:

  "Note that the value of alarmModelVarbindIndex assumes
  the existence of the first two obligatory varbinds in
  the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0
  and snmpTrapOID.0).  That is, a value of 1 refers to
  sysUpTime.0, and a value of 3 refers to the first varbind
  after snmpTrapOID.0.

  If the incoming notification is instead an SNMPv1 Trap-PDU and
  the value of alarmModelVarbindIndex is 1 or 2, an appropriate
  value for sysUpTime.0 or snmpTrapOID.0 shall be determined
  by using the rules in section 3.1 of [appropriate reference
  for RFC2576]."

That way, a 1 always means sysUpTime and a 3 always means the
first "real" varbind.

Did I understand what you want?  Does this work?

Cheers,

dlp