Just a note to inform everybody that I've converted the OPENNMS-MIB definition (packaged as OPENNMS_HOME/contrib/opennms.mib) to conform to version 2 of the structure of management information (SMIv2). This involved mostly just changing the IMPORTS clause at the top of the MIB definition to refer to SNMPv2-SMI and SNMPv2-TC rather than RFC1155 et al, plus a bit of re-jiggering to transform all the TRAP-TYPE macros into the newer NOTIFICATION-TYPE.
The new version of the MIB is substantially identical to the old one. I've verified, for instance, that running the old (SMIv1) and new (SMIv2) versions of this file through mib2events produces 100% identical output. What does this mean to you? If you use OpenNMS to receive SNMP traps, but not to send them, then you do not need to take any action. If you are an OpenNMS maintainer or contributor, and have plans to make additions or changes to the OPENNMS-MIB definition, then you should familiarize yourself with the differences between SMIv1 and SMIv2. Most importantly, you *must* train yourself to update the MODULE-IDENTITY macro's LAST-UPDATED and REVISION macros each time you make changes in this file. Good hygiene in this file is important to the image of the OpenNMS project in the broader network management field. Since you already use smilint to check your work (right?), this should be a non-issue. If you are a consultant type who periodically loads the OPENNMS-MIB into some third-party application that cannot automatically detect whether a MIB conforms to SMIv1 or SMIv2, you might need to tell it the next time around. Even if you think your tools can handle the change, it's probably a good idea to go ahead and try this now in the interest of avoiding surprises the next time you need to do it in the field. If you are a third-party software provider whose product knows how to receive SNMP traps from OpenNMS, you should verify that your build system can handle the latest version of this file. If you are a third-party software provider who redistributes OpenNMS either alone or as part of an assembled work, and you include the OPENNMS-MIB or information about it in your documentation, then you should flag that section of your docs for review and possible update. If you are a technical writer charged with reviewing and possibly updating documentation related to the OPENNMS-MIB, welcome! Have you considered how nice it would look on your CV / resumé if you volunteered a bit of your time helping out on documentation for a really cool free / open-source project such as OpenNMS? :D If you think that SNMP is for sending mail, or that a trap is for catching wild animals, then I cannot help you ;) Cheers, -jeff ------------------------------------------------------------------------------ Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
