My approach is to allocate the top several layers for a break-down, leaving the
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

> On Fri, 11 Jun 2004 11:17:08 -0400 [EMAIL PROTECTED] wrote:
> 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"
> 




-------------------------------------------------------
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
_______________________________________________
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

Reply via email to