[cacti-announce] Cacti 0.8.6j Released (fwd)

Travis H. travis+ml-nanog at subspacefield.org
Thu May 17 05:11:00 UTC 2007


On Wed, May 09, 2007 at 10:25:14AM +0100, michael.dillon at bt.com wrote:
> A MIB is the database schema for an object-oriented hierarchical
> database. The key words there are schema and hierarchical.

A-ha!

So when they say "object" as in "OID", they are referring to stuff in
the MIB database?  Okay, now many things are beginning to make more
sense.  By itself, that word gives no clue as to what it refers to.
For that matter, it'd be nice if someone defined LDAP's use of the
word "attribute", too.

Drift:

LDAP too uses ASN.1, in fact the same OIDs used by SNMP, and in the
O'Reilly book it mentions that it is possible to define different
matching rules for each class.  Now, do they mean that somehow, this
MIB syntax can actually encode an algorithm in some kind of hideous
turing-machine-gone-mad, and that I've got to worry about malicious
MIBs, or does it just refer to a routine implemented elsewhere?

> Schema means
> that it describes how the data is organized

Should read: ``Schemata describe how the data are organized''

Stigma, stigmata; schema, schemata

:-)

Forgive me if I digress into ASN.1 very briefly; it apparently rears its
ugly head in numerous places in cryptography as well as networking, and
I have struggled with it a bit.

Based on what I have read, this syntax is "abstract" in the sense that
it says something like "class C is composed of a DATE object, TIME
object, and BLARG object", without specifying how to encode or decode
any of those objects into some concrete form either for the user or to
put in a packet to send to another system.  The encoding and decoding
is done with a "transfer syntax", and interpreting it for a human
(that is, figuring out a way to represent it) is yet another unsolved
problem.  Sounds a lot like stone soup (or XML) to me.

> That would work but it can be tricky to get the RIGHT MIBs that match
> the data actually available in your device. Also, reading MIBs can be
> misleading because you will see things that look great, but don't work
> because they are deprecated

Those of you who use this word frequently may be amused at its definition:

To pray against, as an evil; to seek to avert by prayer; to seek
deliverance from; to express deep regret for; to desire the removal
of. [archaic]

> Now you see where the SNMP alligator swamp lies. If you are building
> your own network management applications, you may be happier only
> putting the MIBs on the development machines, and putting the numeric
> keys into your application code, or better yet, into your application's
> config file. MIBs have lots of stuff that you probably don't need unless
> you are allowing users to browse through and query arbitrary data.

Yeah, at this point I'm just playing around and exploring,
and so want the MIBs to make sense of the numbers.
-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -><- <URL:http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email john at subspacefield.org.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070517/c80e1ee4/attachment.sig>


More information about the NANOG mailing list