Subject: RE: Loading RFC 2108 802.3 Repeater MIB into OpenView NNM.

From: John Flick <[email-masked]>
Date: Mon, 1 Dec 1997 15:33:58 -0800 (PST)

Andrew Smith writes:
 > Are you proposing to fix this in a revised RFC? Or is this just a local
 > hack to be applied at all HPOV sites? :-) 

It is a local hack, though we may want to keep it in mind the next
time this RFC comes up for review.

 > I had a similar problem with HPOV and draft-ietf-hubmib-mau-mib-04.txt
 > that I raised a few months back. Can we change the trap definitions on
 > that draft too please?

The MAU MIB draft has already been published as RFC 2239.  It is long
past the point where we can change it.

 > Do you know of a new rev of HPOV that can handle
 > the RFC & MAU draft unchanged?

I don't work for the division that does OV.  I don't know if there is
a newer version.  Check with your HP support contact.

 > P.S. Is draft-ietf-hubmib-mau-mib-05.txt scheduled for discussion at
 > IETF anywhere/time?

No.  See above.

John

---

From: "Brian O'Keefe" <[email-masked]>
Date: Mon, 01 Dec 1997 16:45:12 -0700

>  > the RFC & MAU draft unchanged?

No.  See my other email.

bok

---

From: Andrew Smith <[email-masked]>
Date: Mon, 1 Dec 1997 14:38:04 -0800

John,

that draft too please? Do you know of a new rev of HPOV that can handle

Andrew

***********************************************************************
Andrew Smith                            tel: +1 (408) 863-2821
Extreme Networks                        fax: +1 (408) 342-0990
10460 Bandley Drive                     http://www.extremenetworks.com
Cupertino CA 95014                      em:  [email-masked]
***********************************************************************

> -----Original Message-----
> From:	John Flick [SMTP:[email-masked]]
> Sent:	Monday, December 01, 1997 2:15 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Loading RFC 2108 802.3 Repeater MIB into OpenView NNM.
> 
> [email-masked] writes:
>  >      NNM didn't like the NOTIFICATION-TYPE's and the end, even
> though it 
>  >      should be SNMPv2C compliant. Is the NOTIFICATION-TYPE defined
> in a 
>  >      RFC?
> 
> NOTIFICATION-TYPE is defined in RFC 1902.  NNM does understand
> NOTIFICATION-TYPE, but it seems to have problems with the OID value
> assigned to the notifications in 2108.  For example, the value of the
> rptrInfoHealth notification is { snmpDot3RptrMgt 0 4 }, which NNM
> chokes on.  It doesn't seem to like having more than two OID
> components in the value, though I believe this is a legal (though
> unusual) construct.
> 
> One workaround may be to define a new OID:
> snmpDot3RptrTrapPrefix OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 0 },
> and modify the NOTIFICATION-TYPE values to use this prefix.  In the
> example above, rptrInfoHealth would have the value
> { snmpDot3RptrTrapPrefix 4 }.  This does mean editing the MIB to make
> it acceptable to NNM.
> 
> Does anyone have a better workaround for this?
> 
>  >      The rest compiled ok, but e.g. the rptrAddrSearchTable is
> missing when 
>  >      using the MIB browser. Is it supposed to be directly under 
>  >      snmpDot3RptrMgt or further down the tree?
> 
> The path to this tree is:
> snmpDot3RptrMgt.rptrAddrTrackPackage.rptrAddrTrackRptrInfo.rptrAddrSea
> rchTable
> 
> Note that this is a rather new table, so there are likely to be many
> repeater agents out there that don't support this table yet.
> An agent that does not support this table would not return it when you
> are browsing that agent.
> 
> Hope this helps.
> 
> John