More insight into walking the notification log mib

This is a follow-up to my previous question about not being able to walk
the notification log mib.  I now believe there is an actual problem
related to the 5.3.1 code and its internal table walking.

The notification log mib as specified in the RFC and as implemented in
the code does not fully populate all columns.  If I populate each of the
columns in the nlmLogTable row, I can then walk the nlmLogTable.  By
careful interpretation of the RFC I believe this is still compliant.
However, the RFC specifically states that for the nlmLogVariableTable
that only the object identified by nlmLogVariableType should exist -
none of the other columns should be instantiated.  This means that the
same trick I did for nlmLogTable can not be applied to the
nlmLogVariableTable because it would result in a non-conformant
implementation.

So the question is, is the internal handling of tables in the 5.3.1 code
busted because the GETNEXT processing does not cross non-existent
columns or is the notification log mib implementation busted because it
uses the internal data handlers for data that is too complex for that
codes GETNEXT processing?

Does anybody have any clues/opinions on this?

Jeff

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users