[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-ospf-mib-update-04
Spencer,
Sure, I'm in no hurry. I just think that when a MIB goes to full Standard
it should be as near perfect as possible.
I'm not familiar with how this WG does things, so I'll leave it up to you
what you do with the information I'm presenting.
Cheers.
Ken
> -----Original Message-----
> From: Spencer.Giacalone@predictive.com
> [mailto:Spencer.Giacalone@predictive.com]
> Sent: Thursday, October 19, 2000 4:38 PM
> To: Chapman, Ken
> Cc: djoyal@quantumbridge.com; fred@cisco.com; mibs@ops.ietf.org;
> ospf@discuss.microsoft.com; rcoltun@redback.com
> Subject: RE: draft-ietf-ospf-mib-update-04
>
>
> Ken- what mean is, that a lot of what you picked up is not
> stuff that was
> added in our updates. Can we table this until I get a chance
> to take a
> look, please? Thanks.
>
>
>
>
>
>
> "Chapman, Ken" <KChapman@unispherenetworks.com>
> 10/19/00 04:12 PM
>
>
> To: "'Spencer.Giacalone@predictive.com'"
> <Spencer.Giacalone@predictive.com>
> cc: djoyal@quantumbridge.com, fred@cisco.com,
> mibs@ops.ietf.org,
> ospf@discuss.microsoft.com, rcoltun@redback.com
> Subject: RE: draft-ietf-ospf-mib-update-04
>
>
> Spencer,
> How do you interpret RFC2578, clause 7.7 paragraph 3?
>
> "
> The syntax of the objects in the INDEX clause indicate how to form
> the instance-identifier:
>
> (1) integer-valued (i.e., having INTEGER as its underlying primitive
> type): a single sub-identifier taking the integer value (this
> works only for non-negative integers);
> "
>
> I'm sorry, but I really don't think that that is "legacy".
> Ken
>
> > -----Original Message-----
> > From: Spencer.Giacalone@predictive.com
> > [mailto:Spencer.Giacalone@predictive.com]
> > Sent: Thursday, October 19, 2000 3:31 PM
> > To: Chapman, Ken
> > Cc: djoyal@quantumbridge.com; fred@cisco.com; mibs@ops.ietf.org;
> > ospf@discuss.microsoft.com; rcoltun@redback.com
> > Subject: RE: draft-ietf-ospf-mib-update-04
> >
> >
> > Hold on there, guy. All lot of what your finding is legacy..
> > I don't know
> > if I agree with turning everything on in your .inc file- you
> > might want to
> > think about that...
> >
> >
> >
> >
> >
> >
> > "Chapman, Ken" <KChapman@unispherenetworks.com>
> > 10/19/00 02:57 PM
> >
> >
> > To: "'Spencer.Giacalone@predictive.com'"
> > <Spencer.Giacalone@predictive.com>
> > cc: djoyal@quantumbridge.com, fred@cisco.com,
> > mibs@ops.ietf.org,
> > ospf@discuss.microsoft.com, rcoltun@redback.com
> > Subject: RE: draft-ietf-ospf-mib-update-04
> >
> >
> > Spence,
> > I'm using SMICng (v2.2.07), and that is how I found these.
> > You have to enable all the checking (except B, which I think is
> > inconsistant
> > with RFC2578).
> >
> > Now, I've found more bugs.
> >
> > Integer objects used as INDEX (auxiliary) objects can't be negative
> > (RFC2578
> > clause 7.7 bottom of page 27).
> > Therefore, you need to change the SYNTAX for ospfAddressLessIf,
> > ospfIfMetricAddressLessIf, ospfNbrAddressLessIndex, and
> > ospfLocalLsdbAddressLessIf from Integer32 to Unsigned32.
> > Note that ospfNbrAddressLessIndex actually uses the
> TEXTUAL-CONVENTION
> > InterfaceIndex, which conflicts with the TC in the IF-MIB
> > with the same
> > name
> > and therefore should not be used (besides, you really want
> > the full 32
> > bits
> > to accomidate IP addresses).
> > Therefore I recommend using Unsigned32 and removing the
> > InterfaceIndex TC
> > altogether.
> >
> > For consistancy (with updating to SMIv2), I suggest importing
> > mib-2 from
> > SNMPv2-MIB rather than RFC1213-MIB.
> > (This is not a bug, but... RFC1213 should be retired, IMHO.)
> > Ken
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++
> > Ken Chapman Unisphere Networks, Inc.
> > Tel: +1-978-614-5322 5 Carlisle Drive
> > Fax: +1-978-692-9992 Westford, MA 01886
> > Email: KChapman@UnisphereNetworks.com
> > ++++++++++++++++++++++++++++++++++++++++++++++
> >
> >
> >
> > > -----Original Message-----
> > > From: Spencer.Giacalone@predictive.com
> > > [mailto:Spencer.Giacalone@predictive.com]
> > > Sent: Thursday, October 19, 2000 1:13 PM
> > > To: Chapman, Ken
> > > Cc: djoyal@quantumbridge.com; fred@cisco.com; mibs@ops.ietf.org;
> > > ospf@discuss.microsoft.com; rcoltun@redback.com
> > > Subject: Re: draft-ietf-ospf-mib-update-04
> > >
> > >
> > > Ken,
> > >
> > > Thanks. The first might be a fat finger on my part, but SMIC
> > > didnt pick
> > > the rest up. Let me take a look and get back to you. Imports
> > > might be a
> > > legacy thing.
> > >
> > > Spence
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Chapman, Ken" <KChapman@unispherenetworks.com>
> > > 10/19/00 11:41 AM
> > >
> > >
> > > To: "'ospf@discuss.microsoft.com'"
> > > <ospf@discuss.microsoft.com>
> > > cc: "'spencer.giacalone@predictive.com'"
> > > <spencer.giacalone@predictive.com>,
> > > "'djoyal@quantumbridge.com'" <djoyal@quantumbridge.com>,
> > 'Rob Coltun'
> > > <rcoltun@redback.com>, "'fred@cisco.com'" <fred@cisco.com>,
> > > "'mibs@ops.ietf.org'" <mibs@ops.ietf.org>
> > > Subject: draft-ietf-ospf-mib-update-04
> > >
> > >
> > > Hi,
> > > I'm not a regular on this list and don't know a whole lot
> > > about OSPF; I'm
> > > just an SNMP geek.
> > > But I found some bugs in the MIBs, and I didn't see any
> > > issues raised in
> > > the
> > > archives.
> > >
> > > There is a bug in OSPF-TRAP-MIB:
> > > The last object imported from OSPF-MIB is
> > > "ospfAreaExtNssaTranslatorStatus";
> > > it should be "ospfAreaNssaTranslatorState".
> > >
> > > There are some minor "conformace" issues with the MIBs as
> presented:
> > >
> > > The "00" year part of the dates in the LAST_UPDATED and
> > > REVISION clauses
> > > need to be "2000"
> > > (ref: RFC2578 clause 2 (top of page 5).
> > >
> > > ospfAuthType is not included in any OBJECT-GROUP definition.
> > >
> > > None of the notifications in OSPF-TRAP-MIB are included in a
> > > NOTIFICATION-GROUP.
> > > (note: don't forget to import NOTIFICATION-GROUP from SMIv2-CONF.)
> > >
> > > While the last two are not violations per se (as far as I can
> > > tell from
> > > reading RFC2580),
> > > it makes it difficult to include these items in an
> > AGENT-CAPABILITIES
> > > definition.
> > >
> > > I hope this is helpful.
> > > Cheers.
> > > Ken
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>