Subject: (ION) Putting NOTIFICATION-TYPEs in their place

From: Gary Hanson <[email-masked]>
Date: Fri, 23 Jan 1998 13:26:19 -0800 (PST)

Hi folks,

A close reading of section 8.5 of RFC 1902 and the referenced section
3.1.2 of RFC 1908 indicates that if a notification is NOT carefully
placed in the OID hierarchy (i.e., if the next to last sub-identifier
in the name of the notification does NOT have the value zero) then
compatibility problems can result between SNMPv1 and SNMPv2 entities
that use the notification.

How serious is this problem in actuality?  Would somebody explain the
specific scenario that wouldn't work as we would expect if we were to
define, for example, "fooEvent" as "{ fooMIB(1) fooNotifications(1) 1 }"
instead of as "{ fooMIB(1) fooNotifications(1) fooTrapPrefix(0) 1 }".

(I think this would probably be a good item for The Simple Times FAQ,
so I copied the editors there, too.  Perhaps it is already answered in
one of the back issues....)

I see a number of standards track MIBs that faithfully follow this
prescription of using a zero value in the next to last sub-identifier:
  - ENTITY-MIB (RFC 2037)
  - ISDN-MIB (RFC 2127)
  - DIAL-CONTROL-MIB (RFC 2128)
  - RSVP-MIB (RFC 2206)
  - ATM2-MIB (draft-ietf-atommib-atm2-11.txt)
  - DS1-MIB (draft-ietf-trunkmib-ds1-mib-06.txt)
  - DS3-MIB (draft-ietf-trunkmib-ds3-mib-05.txt)
  - EVENT-MIB (draft-ietf-disman-event-mib-02.txt)
  - IPV6-MIB (draft-ietf-ipngwg-ipv6-mib-03.txt)
  - NOTIFICATION-MIB (draft-ietf-disman-notify-mib-01.txt)
  - PTOPO-MIB (draft-ietf-ptopomib-mib-01.txt)
  - SLP-MIB (draft-ietf-svrloc-slp-mib-00.txt)
  - TEST-MIB (draft-ietf-ifmib-testmib-03.txt)

However, I sometimes see standards track MIB internet-drafts that
do NOT follow this prescription, and I am just wondering what their
fates will be if they are not nudged into compliance in this area.

Some examples from the internet-drafts created by the ion WG:
  - IPATM-IPMC-MIB (draft-ietf-ion-mars-mib-04.txt)
  - IPOA-MIB (will be fixed in draft-ietf-ion-mib-06.txt)
  - SCHEDULE-MIB (draft-ietf-disman-schedule-mib-00.txt)
  - SCSP-MIB (draft-want-ion-scsp-mib-00.txt)

Note that the SLP-MIB defines its NOTIFICATION-TYPE under an overlying
NOTIFICATION-GROUP, which I don't think was intended, and I am not sure
if it is kosher, either, although it does use the zero value prefix.

I cross-posted this to the ion WG because of the exposure in that WG.
I would not be surprised if there are other MIBs under development in
other WGs that may need similar attention.

Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 1998 14:45:59 +0100

>>>>> Gary Hanson writes:

Gary> A close reading of section 8.5 of RFC 1902 and the referenced
Gary> section 3.1.2 of RFC 1908 indicates that if a notification is
Gary> NOT carefully placed in the OID hierarchy (i.e., if the next to
Gary> last sub-identifier in the name of the notification does NOT
Gary> have the value zero) then compatibility problems can result
Gary> between SNMPv1 and SNMPv2 entities that use the notification.

Gary> How serious is this problem in actuality?  Would somebody
Gary> explain the specific scenario that wouldn't work as we would
Gary> expect if we were to define, for example, "fooEvent" as "
Gary> { fooMIB(1) fooNotifications(1) 1 }" instead of as "{ fooMIB(1)
Gary> fooNotifications(1) fooTrapPrefix(0) 1 }".

The most convincing reason for me why the 0 sub-identifer should be
there are proxies converting SNMPv1 traps into SNMPv2 traps without
MIB knowledge. Take an SMIv2 MIB, convert it to SMIv1 and implement it
in an SNMPv1 agent. Now, your SNMPv1 agent sends a trap and a proxy
converts this trap into a SNMPv2 trap. You only get the notification
OID back if the registration has a 0 sub-identifer as the next to last
subidentifier.

Gary> I see a number of standards track MIBs that faithfully follow
Gary> this prescription of using a zero value in the next to last
Gary> sub-identifier:

[snip]

Gary> However, I sometimes see standards track MIB internet-drafts
Gary> that do NOT follow this prescription, and I am just wondering
Gary> what their fates will be if they are not nudged into compliance
Gary> in this area.

I think that internet-drafts not following this prescription should be
fixed before they get published as RFCs. (I can assure you that the
next version of the SCHEDULE-MIB contains this change.)

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3283)