Harrie Hazewinkel writes:
Harrie> I indeed agree with the fact "BROKEN MIBS ARE BROKEN!", but Harrie> those MIBs are used. I also beleive it would be good practise Harrie> of them to fix their MIB modules, but will they really do?? I Harrie> have seen MIB modules around for a long time which were even Harrie> half SMIv1 and half SMIv2. When I mentioned this to them they Harrie> did not care about it. It worked for them and probably there Harrie> customers.
Harrie> I believe we need to build in some flexibility that things Harrie> will work regardless if the MIB module is broken (in the full Harrie> sense). Of course it should recover those errors which it can Harrie> and obvious mistakes. This is not so much a requirement for Harrie> libsmi itself as used stand-alone, but it is (IMHO) a Harrie> requirement for applications that embed libsmi. It brings the Harrie> use of libsmi to another level, of not just checking the Harrie> correctness of the MIB module.
I have a strong opinion about this: Broken MIBs should be rejected.
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.
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.
/js -- !! 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.