[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Nesting levels in existing mibs



Title: Nesting levels in existing mibs

Hi Frank,

I believe it is important for existing applications to be able to continue to work with the existing mibs. As a goal, the members of the meeting seemed happy with the approach that existing mibs do not get extended with the new functionality.

If you add SMIv2-incompatible extensions to existing mibs, then they may not work properly unless the applications are modified; if they require modification to understand when n>1 then they are no longer the existing applications.

Andy's proposal for OID indexing to n>1 levels was also found to be a reasonable approach by the members of the meeting. I don't know what you have in mind.

I don't mind supporting such a thing if it would be not delay the development of SMIv3, and would be easy to understand for human mib readers and mib writers.

I certainly see that mib-writers working on existing SMIv2 mibs could easily make a mistake of adding an SMIv3 feature to an SMIv2 mib and cause problems for existing applications. A solution as simple as "an SNMPv1 agent doesn't recognize Counter64 typed objects for an SNMPv1 request" would suit me.

But before I throw behind my support such a goal, I need to be convinced it is feasible; can you elaborate on your proposal of how to achieve it within the scope of Andy's OID nesting?.

 
Can you explain how we can
1) use Andy's approach to OID nesting
2) add nesting levels to existing mibs
3) allow existing applications, without modifications, to continue to work with existing mibs that have been extended?

dbh


> -----Original Message-----
> From: Frank Strauss [mailto:strauss@ibr.cs.tu-bs.de]
> Sent: Wednesday, September 18, 2002 3:14 AM
> To: Andy Bierman
> Cc: 'sming@ops.ietf.org'; Durham, David
> Subject: Re: SMIng consensus issues restated, call for consensus ends
> Septembe r 18, 2002
>
>
> Hi!
>
> I think we move in circles. The major point in which we have separate
> opinions is that
>
>  - you clearly separate between existing MIBs (that cannot benefit
>    from some new SMI-DS features when they are revised) and new MIBs,
>    while
>
>  - I prefer a change from which both cases can benefit, but with the
>    disadvantage that the data structures at levels > 1 cannot be
>    addressed explicitly.
>
> Do you agree, Andy?
>
> I would also really appreciate comments on my reservations from other
> WG members.
>
>  -frank
>