Import MIBs for Alerting

Agreed. I actually just had this situation come up and it would be awesome to be able to simply import the *.my files rather than manually looking up OIDs

This has come up several times and would be really valuable IMO. The product team sees that vision, but has found it difficult to justify since every time it comes up, only one customer is interested (glad to see more now) and it would take a non-trivial amount of work to get something like this built.  It has been and will be a hard sell to justify it, but I think we should all push for it.

To flesh out your request (and get some of my own thoughts around it written down), here's how I see the workflow. Please give me feedback on how you'd like to see this work. 

Customer starts "Add new datasource" workflow:

1. 1. Give it a name, display name, description, tech notes (which may get adjusted in a later step), group, and applies to. Select the "Collector" snmp, script, wmi, etc. If SNMP is selected...
2. 2. You are prompted to go manually (traditional route) or based on a MIB. If traditional, rest of today's DS settings are filled out as today.
3. 3. If "based on a MIB" is selected, you are shown the MIB library (new feature, see how this gets bigger and bigger?) and asked to pick a MIB table from the tree (if the MIB isn't in the MIB library there should be an option right here to upload the MIB). 
4. 4. Once the MIB table is selected, you need to pick:
5.  - whether single or multi-instance
6.  - which column(s) will be the wildvalue
7.  - which column(s) will be the wildalias
8.  - which column(s) will be added as instance properties
9.  - which column(s) will be added as data points
10. 5. While doing the above, you should have the option to do a test poll, returned in tabular format, against any device in the appliesto.
11. 6. With that done, there should be a "generate" button that will generate the discovery script (similar to this so that enumerated properties are usable) and the collection script (this might be doable with simple datapoints and not a script, tbd). This generate action may populate some of the tech notes with info from the MIB. Datapoints should have descriptions from the OIDs, including enumerations of custom syntaxes. 
12. 7. User can run tests of active discovery and of collection to ensure stuff comes out right. User may need to add discovery filters, complex datapoints, datapoint post processing, etc.

So, this requires a new feature, a MIB library, to exist in LM. Does that exist as a single library for all customers? Probably not because customers will need their own versions of MIBs sometimes. Do we create it as a master library and if you upload a different MIB, that MIB's branch is only changed for you? Lots of logistics to work out there.

Technically, having this MIB library would also make it much easier to create SNMP PropertySources using a very similar workflow to what's described above. 

Technically, having this MIB library would also make it much easier to create SNMP EventSources from traps defined in the MIB. We discourage heavily relying on traps for (hopefully) obvious reasons.  This could be designed to be intentionally clunky to discourage users from selecting all traps and defining hundreds (or thousands) of mostly useless EventSources.

Some of the hurdles we will encounter:

1) Is SNMP going to continue to be as popular going forward as it is today given the rise of other collection mechanisms (WMI, API, etc.)? 
2) What does it look like when a DS created using this method needs to be edited?
3) What happens when a new MIB is uploaded that affects a DS already built?
4) What does the MIB library need in order to work securely?

We'd need to show that this feature would give LM feature parity with existing SNMP tools.

I second this.  This would be a great addition.