Ok, so do you mean that I shouldn't put anything that's already in MIB-II in our private MIB if we include MIB-II support in our product? When I said "the same data" I really should have said that there might be a few data points that would be duplicated between the 2 (like IP addresses). Would it be best to just not include any default MIB support and only support our private MIB in that case? I was told that most shops would want at least MIB-II support, and then if they want to peruse our data they could go to our enterprise OID. And I've been told that it's really traps that are the most important aspect of our SNMP support (from our customer's perspective), so I'm not even sure how our "private" data will be used, if at all, by the customer.
Our GUI doesn't use SNMP - it's CIM based (not my choice). We're adding SNMP support after-the-fact, so they want the SNMP data to "mirror" what we're doing in CIM (and even there we defined everything under our own objects). When I post my MIB for review, should I just put the whole thing in the body of the email and title it "MIB for review"?? I don't want to clog up the mailing list. Thanks Dave! ~ Wendy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Shield Sent: Tuesday, January 08, 2008 4:47 AM To: McGowen, Wendy Cc: net-snmp-users@lists.sourceforge.net Subject: Re: Enterprise trapquestion/send_v2trap API call On 07/01/2008, McGowen, Wendy <[EMAIL PROTECTED]> wrote: > I have one last section to add, our own > network support - TPTB don't want full SNMP support in the product, > and they haven't decided if leaving MIB-II turned on shows too much > information. That's fine - it's perfectly reasonable for a vendor to decide what information to report or omit. Either for reasons of security, or processing load. > And even if we leave in MIB-II, they want me to add the > same data to our MIB That's not so fine. The whole point of Network Management standards is that they are standard - consistent - the same. A network admin should be able to query *any* box on the network (regardless of vendor) using the same standard OIDs, and get the relevant information (assuming it's supported). Having to use one OID for one vendor, and a different OID for another is flying in the face of everything that SNMP stands for. Tell your PTB that they're talking nonsense! Or put in language that they might understand - if I'm faced with a choice between purchasing equipment from a vendor that has followed the standards, and one that's gone their own merry way, I will tend to recommend that we go with the vendor that's followed the standards. You can still use the standard OIDs for your management GUI, so it shouldn't make any difference to the functionality of your product, whichever way you choose. But it might cost you sales if you ignore Best Practise. Dave ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
