ASN.1 is quite concrete, and specifys several encoding methods (I prefer BER myself) :) I'm not saying everyone would consider it pretty, but it's quite concrete ... Check out http://lionet.info/asn1c/ On 5/17/07, Travis H. <travis+ml-nanog@subspacefield.org> wrote:
On Wed, May 09, 2007 at 10:25:14AM +0100, michael.dillon@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@subspacefield.org.