On 14/10/06, Steve Friedl <[EMAIL PROTECTED]> wrote:
> I have my own spanking fresh Enterprise OID number on the way from IANA,
> We're going to use these for both SNMP and LDAP
OK - well, you could probably do worse than learn from the experiences
of the standard OID structure - i.e. the organisation immediately
below the "internet" object (1.3.6.1)
This consists of:
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
security OBJECT IDENTIFIER ::= { internet 5 }
snmpV2 OBJECT IDENTIFIER ::= { internet 6 }
So they also started by having completely separate trees for
SNMP-related management information (mgmt(2)) and LDAP-style directory
information (directory(1)).
experimental(3) was intended as a temporary holding area while new
standards, etc were being developed. My impression is that this idea
never really worked - with people tending to use private areas
instead. However it might work better in a more localised
environment. (And the Net-SNMP project has tried something similar
with the nsPlayPen subtree).
Whether you need an equivalent of "private(4)" is up to you - perhaps
set aside an area for each developer or researcher that might be
working with this stuff.
> When I need to change my whole OID
> structure around or create a second, unrelated project, I'm not sure how
> to make a "version 2", so this suggests some pre-planning to allow room
> for growth.
Well, you have 2^32 subidentifiers available under your enterprise
number, and 2^32 subidentifiers available under each of those, and
2^32 subidentifiers available under each of *those* - etc, etc, up to
a maximum of 127 levels. So you should have plenty of room for
expansion! (Though that 127 does need to cover index values as
well).
But once you've defined a MIB object (at least publically), you
can't subsequently change it. All you can do is mark it as deprecated
(or obsolete) and define a replacement somewhere else in the tree.
Given the space you've got to work in, this isn't likely to prove too
restrictive :-), but it's perhaps worth putting some general structure
in place first.
Have think about the structure of your organisation - it might be
worth having a subtree for each division or project group - or perhaps
one for each general type of product.
> We're also creating our own LDAP objects, and though I am almost certain
> that the two systems (LDAP and SNMP) have their own namespaces, it would
> not surprise me if it were a good idea to not allow overlap.
See above - if you define an LDAP subtree and an SNMP subtree, then
you can keep things completely separate. OK - it means that you waste
one whole level of your subtree (plus the seven subidentifiers
defining your enterprise OID) - but you've still got 119 to play with.
That should be sufficient for a fairly deep OID structure, and still
leave plenty of room for index values.
> I'd surely love some guidance.
Have a look at some of the privately defined MIB files - both those
shipped with the Net-SNMP suite, and any others you can find. That
should give you some idea about how various other people have tackled
this - both ways that make sense to you, and approaches that don't
seem sensible at all.
There's no One Right Way to do this. Just experiment and find
something that works for you.
Dave
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
