Subject: RE: [Disman] varbind offsets in alarm-mib-15

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 13:57:18 -0400

Hi

Working group consensus was to translate from v1 traps to Notifications,
which is what we did for storage. I've just looked at the discussion in the
archive.

Subsequent discussion, and this is more from memory, talked about designing
alarm models and discussed the fact that people would be designing them off
the SMI, not the bits on the wire so it might be confusing to include the
sysUptime and trap OID in the numbering. I remember Dave Partain saying
something along the lines that he didn't care which way it was done so long
as it was properly explained in the ID. I proposed the method in the current
draft and I don't remember any objections.

Sharon 

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Friday, October 03, 2003 1:17 AM
To: Disman (E-mail)
Subject: [Disman] varbind offsets in alarm-mib-15

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" 
> <[email-masked]>; "Romascanu, Dan (Dan)"
<[email-masked]>
> Sent: Monday, September 29, 2003 7:34 AM
> Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt

...
> 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry) I repeat 
> my comments from May, since they're still not reflected in the
> draft:
>
> > The words that are there now seem to be backwards from what I 
> > thought was agreed: since RFC 3416 is Standard, and 1157 is 
> > Historic, that the numbering should start with 1 for the SysUptime, 
> > which would be the value extracted from elsewhere in the PDU in the 
> > case of a SNMPv1 trap.  What's there now (still) seems unnecessarily 
> > confusing.
> >
> > Note that Harrie Hazewinkel's message of March 18, 2003 also has 
> > concerns with this same paragraph.
> >
> > The discussion back in April 22, 2002 went the same way, and 
> > Sharon's post of June 3, 2002 gave the resolution of issue #38 as 
> > being to treat everything "v2-style".
>
> Sharon-> See Section 3.6 of the document
...

The text now reads:
3.6 Notification Varbind Storage and Reference

   In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire
   map one to one into those varbinds listed in the SMI of the trap in
   the MIB in which it was defined[RFC1215]. In the case of linkDown
   trap, the first varbind can unambiguously be identified as ifIndex.
   With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU
   types, which send sysUptime and snmpTrapOID as the first two
   varbinds, while the SMI in the MIB where the Notification is defined
   only lists additional varbinds, the meaning of "first varbind"
   becomes less clear. In the case of the linkDown Notification,
   referring to the first varbind could potentially be interpreted as
   either the sysUptime or ifIndex.

   The varbind storage approach taken in the Alarm MIB is that
   sysUptime and snmpTrapOID SHALL always be stored in the active alarm
   variable table as entry 1 and 2 respectively, regardless of whether
   the transport was the Trap-PDU, the InformRequest-PDU or the
   SNMPv2-Trap-PDU. If the incoming Notification is an SNMPv1 Trap-PDU
   then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be
   determined by using the rules in section 3.1 of [RFC3584].

So far, so good.  But then the next paragraph says:

   The varbind reference approach taken in the Alarm MIB is that, for
   variables such as the alarmModelVarbindIndex, the first two
   obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are
   ignored, and the index aligns with the Trap-PDU and the SMI. In the
   case of linkDown, the first varbind would always be ifIndex.

This seems unnecessarily convoluted, and results in an even more complicated

   alarmModelVarbindIndex  OBJECT-TYPE
      SYNTAX  Unsigned32
      MAX-ACCESS   read-create
      STATUS       current
      DESCRIPTION
        "The index into the varbind listing of the notification
        indicated by alarmModelNotificationId which helps
        signal that the given alarm has changed state.
        If there is no applicable varbind, the value of this
        object MUST be zero.

        Note that the value of alarmModelVarbindIndex ignores
        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
        the first varbind after snmpTrapOID.0.

        If the incoming notification is instead an SNMPv1 Trap-PDU,
        then a value of 1 refers to the first varbind."
        DEFVAL { 0 }
       ::= { alarmModelEntry 4 }

As a technical contributor, I think it's really twisted to warp everything
into an SNMPv1 point of view.  1 should refer to the first varbind in
alarmActiveVariableTable for a particular alarm.  This is also needed for
internal consistency with the DESCRIPTION of alarmActiveVariableEntry, which
states:

          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 [RFC3584]."

As WG chair, I thought we had a clear consensus to do it the SNMPv3 way.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 17:30:30 -0700

Hi -

> Sent: Saturday, October 18, 2003 10:57 AM
> Subject: RE: [Disman] varbind offsets in alarm-mib-15
...

> which is what we did for storage. I've just looked at the discussion in the

I disagree (with your conclusion, not that you've looked at the archive :-)
The consensus was to use the RFC 2576 approach to normalizing
the payload into the SNMPv2 form.  Which SMI was used to define the PDU
that arrived is irrelevant, and may even be unknowable.  The first varbind
in the PDU should be number one.  To assign any other number to the first
varbind in the PDU would seem highly questionable, as it would seem
highly questionable to claim that any other varbind should be called number one.

...

Objections came from me and from Harrie Hazewinkel, whom I've quoted in
previous discussions.  This argument has been going on since  Spring of 2002.
I've seen no significant support for the position Sharon has advocated.
As WG chair, I'm ruling that the consensus stands: the varbind lists should be
handled v2-style, so that index value one refers to the first variable binding
in the v2-formatted PDU.  If the PDU came from some other protocol or
mechanism, e.g., SNMPv1, then the RFC 2576 rules for mapping it into an
SNMPv2-style PDU apply.  If anyone thinks I have made this ruling in error,
on either process or technical grounds, the applicable appeals process is
described in RFC 2026 section 6.5.1.

Randy
Disman WG chair

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 17:30:30 -0700

Hi -

...

...

Randy
Disman WG chair