Re: Enterprise MIB organization
Robert Story (Users)
CRC> Is there a common, typical, or expected organization of the objects in an
CRC> enterprise MIB? I imagine most vendors have multiple, device-specific
CRC> MIBs. Would I expect to find those organized like:
CRC>
CRC> RFC1155-SMI::enterprises.myent.device1.something
CRC> RFC1155-SMI::enterprises.myent.device2.something
CRC> ...
CRC>
CRC> or
CRC>
CRC> RFC1155-SMI::enterprises.myent.devices.d1.something
CRC> RFC1155-SMI::enterprises.myent.devices.d2.something
CRC> ...
CRC>
CRC> or something else? Thanks.
It varies a lot. If you are writing MIBs, "Understanding SNMP MIBs" is highly
recommended.
One thing I usually do is partition the enterprise space at the top, so the
very top level doesn't get cluttered with device specific nodes.
egtReg OBJECT-IDENTITY
"Sub-tree for registrations"
egtGeneric OBJECT-IDENTITY
"Sub-tree for common object and event definitions"
egtProducts OBJECT-IDENTITY
"Sub-tree for specific object and event definitions"
egtCaps OBJECT-IDENTITY
"Sub-tree for agent profiles"
::= { egtRoot 40 }
egtReqs OBJECT-IDENTITY
"Sub-tree for management application requirements"
egtExpr OBJECT-IDENTITY
"Sub-tree for experimental definitions"
--
Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/>
<irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-users>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
William R. Buckley
device specific OID definitions for a bit later. Consider the problems you face
in maintaining a hierarchical directory structure, with the occasional need to
move a subtree down in the hierarchy, and you will understand the benefit of
building into the MIB structure room to accomodate similar issues. Since
the MIB is *set in concrete* once it is publicly released. If you read some
MIBs from well-established firms, you will occasionally note that they
include such room in their tree.
William R. Buckley
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
Dave Shield
As a third example, the overall framework I set out for the Net-SNMP
subtree is basically defined in NET-SNMP-MIB. This lays out
separate subtrees for:
- real management objects (NET-SNMP-*-MIB)
- example management objects (NET-SNMP-EXAMPLES-MIB)
- "enumerations" (i.e. lists of named OIDs)
- notifications (including notification-only objects)
- conformance definitions
So that's probably closer to your second arrangement, with
'netSnmpObjects' playing the role of your 'devices' object.
Within that subtree, the next level is relatively "flat",
with the groups being divided between the various MIB files
by overall-functional-area, but all being at the same level.
I didn't define separate subtrees for "agent-related" or
"system-related" information.
The one file that is doesn't fit neatly into this model is
NET-SNMP-EXAMPLES-MIB. This has taken a somewhat different
approach, with everything (including the MODULE-IDENTITY and
notification entries) being defined directly under the
'netSnmpExamples' subtree, rather than using the relevant
portions of the wider framework.
That works equally as well - it's just a slightly different
approach.
There's no One Right Way to do this.
Choose something that makes sense to you, and stick to it.
Dave