Hi,
Sorry for not being able to quote, but Lotus Notes is against it :-(
In my opinion, a SMI parser that is used to gain information from a MIB module should be as strict as a SMI parser that for checking a MIB module. I will below explain why.
Today many of the private MIBs are not usable. May be there is some parser somewhere that is able to parse such broken MIBs but what does the enduser gain? Would you want a lenient compiler for a programming language? Would a program compiled with such a lenient compiler be stable? It is the same with MIB files!
We have had so many problems with broken MIBs in the past that we decided to implement a new parser with strict syntax checking that cannot be disabled by option. This is what the majority of our customers embraced, because they had a problem each time a vendor gave them a new MIB to determine whether the MIB will be usable out in the field.
The ENDUSER has the problem that something with the network management system does not work and he does not know why. Is this any better than getting an error message that can be used to solve the problem (either by the enduser or by the author of the MIB)?
If we do not have strict syntax checking that cannot be turned off the vendors will always say "It's working for us!" and they will keep shifting the problem to the enduser.
Regards, Frank
|--------+-----------------------> | | Harrie | | | Hazewinkel | | | <harrie@coval| | | ent.net> | | | | | | 16.07.01 | | | 19:58 | | | | |--------+----------------------->
----------------------------------------------------------------------------|
| | | An: Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de | | Kopie: D.T.Shield@csc.liv.ac.uk, strauss@ibr.cs.tu-bs.de, | | libsmi@ibr.cs.tu-bs.de, (Blindkopie: Frank Fock/MAIN/MC1) | | Thema: Re: [libsmi] Fwd: Re: [PATCH] sturcture name change. |
----------------------------------------------------------------------------|
Juergen Schoenwaelder wrote: [snip]
I have a strong opinion about this: Broken MIBs should be rejected.
I think this is more an academic/perfect world view. NET-SNMP will be used in conjunction of MIB modules shipped by vendors. These vendors are not using NET-SNMP and their customers are using UCD-SNMP without their knowledgde. Now these customers upgrade to NET_SNMP and everything breaks, because of the broken MIB module. Yes, I agree the vendors need to improve their MIB modules. But in real life the customer has a problem directly.
I agree that libsmi could be improved to recover more gracefully in some cases. And this is what I heard Frank saying as well. But adding code to accept modules that for example mix SMI versions is definitely not the direction I want to go.
I agree, that is just an example. Even though, my own MIB compiler is flexible with this.
We are facing the following situation:
(a) There are so many broken MIB because so many lenient parsers do accept them. (b) There are so many lenient parsers that accept broken MIBs because there are so many broken MIBs.
This circular logic needs to be broken up. And the way to do this is to provide people with good parsers that help them to fix the broken modules. Yes, it will not be without pain for everyone. But in the longer term, there will be clear benefits.
I am sure all vendors will agree, but that they fix the problem. The bigger problem is taht sometimes MIB modules are already shipped.
There is also another view of this. Libsmi as such is currently focussed on parsing and testing MIB modules for there syntactical and semantical correctness. Usage of libsmi inside NET-SNMP is I beleive different. It is there focussed on getting more knowledge of the managed objects at the manager side. I beleive that the resulting libsmi need to be that when used as parser/tester it should reject broken MIB modules and when used inside applications it should attempt as much error recovery as possible. After the error recovery it still may provide all problems of the MIB module, but the application may start using it.
Correct me if I am wrong Dave, but I beleive you are looking for something like this too.
Harrie -- address: Covalent Technologies, 645 Howard St, San Francisco, CA - 94105 phone: +1-415-536-5221 fax:+1-415-536-5210 personal website: http://www.lisanza.net/ -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.