Fwd: trap design - theory vs practice

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Below is a message that describes the current state of the art.
It's sad.

Regards,
/david t. perkins

>Date: Thu, 08 Apr 2004 01:37:18 +0100
>From: aparimana <aparimana@camart.co.uk>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
>X-Accept-Language: en-us, en
>To: dperkin@dsperkins.com
>Subject: trap design - theory vs practice
>X-pstn-levels:     (S:99.64681/99.90000 R:95.9108 P:95.9108 M:98.2334 C:87.1726 )
>X-pstn-settings: 3 (1.0000:1.0000) r p m c 
>X-pstn-addresses: from <aparimana@camart.co.uk> [1614/57] 
>
>hello there,
>
>i hope you don't mind me sending you personally my last post to comp.protocols.snmp - i am not sure whether you are reading it at the moment, and your opinion above all i would love to hear....'understanding snmp mibs' is my snmp bible, i guess that makes you my snmp god.... ;-)
>
>all the best,
>
>aparimana
>
>****************************************************
>
>this is a bit of a painful agent design story - if you any angle at
>all on what i'm talking about below, PLEASE post a response to the
>group, i'd love as many opinions as possible....
>
>i've designed an agent to send a trap containing a single oid/value
>pair, of type integer, which references a table cell.  the table has
>four columns, three 'not-accessible'  index columns (strings) plus the
>'read-only' integer column.
>
>the oid part of the oid/value pair in the trap's payload is therefore
>made up of the OID of the integer column, followed by the three
>oid-encoded index strings.
>
>**** so far so good, everyone on this list seems to agree that this is
>a sensible thing to do ****
>
>that's the THEORY, however in PRACTICE....
>
>MANAGERS - i can find *no* managers which decode the index fields of
>the OID when displaying the trap - they *all* display the column name
>followed by raw dot-notation for the index information (**apart from
>mibExplorer**, which changed overnight as a result of my asking
>exactly this question - thanks frank!)
>
>AGENTS - the only agents i have found which send a table cell in a
>trap ALSO send the index fields as SEPARATE oid/value pairs in the
>same trap.  Index columns, of course, are normally 'not-accessible'.
>it would be illegal to send an oid in a trap from a column marked as
>'not-accessible', while marking them as 'read-only' would mess up
>table retrieval by get-next... so the index columns have been declared
>'accessibe-for-notify'!
>
>surely designing an agent's mib this way is madness:
>
>1. index information is being duplicated over and over.  in my case, i
>would need to send four OID/value pairs, and so it would mean sending
>each index FIVE times, four times OID-encoded (once for each of the
>four columns), and once as an unencoded plain-text value
>
>2. 'accessible-for-notify' was never intended to be used like this -
>its mainly there, i thought, for the compulsory OID fields in the
>trap's structure (eg every trap has to send an enterprise OID which
>can be 'accessible-for-notify').  i can see why someone might also use
>it for ephemeral information only relevant to the trap instance (eg a
>sequence identifier so a suitably-written manager knows it has missed
>a trap). but surely never for persistent, important information which
>can be retrieved in other ways?
>
>3. it is not even *legal* to mark index fields as
>'accessible-for-notify' - the RFC's say that index fields should be
>'not-accessible', or 'read-only' in a couple of special cases.  i
>wonder if any mib compilers refuse to compile a mib with an
>'accessible-for-notify' index column?
>
>all that said, however, i *can* see why someone would write a mib like
>this, in despair at managers which refuse to display index information
>in the oid part of traps.
>
>the only other work-around would appear to be to create a scalar,
>'accessible-for-notify' object for each column in the table.  in this
>way, at least, the trap can deliver every cell in the row without
>duplicating so much information, and the mib remains legal (because
>the index columns in the table can remain 'not-accessible'). however,
>the scalars would be logically unrelated to the underlying table,
>which seems a heavy price to pay.
>
>WHY ON EARTH CAN'T MANAGERS DISPLAY THESE TRAPS PROPERLY?
>
>please, i am desparate to know how this situation has come about....
>it is harldly a difficult thing for a manager to display the
>information properly (as frank proved by upgrading mibExplorer in a
>matter of hours).  after all:
>
>1. the same managers *can all* parse the same OID when it comes
>through a get-next instead of a trap
>2. the managers are already comparing the OID to the MIB in order to
>display the column name rather than a raw OID at the beginning of the
>OID path - why stop there?
>
>ANY THORIES?  it's bugging the heck out of me! mainly because i've
>spent so much time over the last few months being accused of designing
>an "unusable, non-standard" mib - "your traps are unintelligible, look
>how snmp-c (our snmp manager) displays them" and eventually, after
>much to-ing and fro-ing "oh for heaven's sake, look at these other
>mibs, you should be able to work out how to do it properly there (gee,
>you really haven't got a clue about how snmp works, have you?)"
>
>is this some kind of conspiracy?  *someone* has to have a relevant
>conspiracy theory :-)
>
>is it because all the managers are written using the same crappy API
>which happens not to parse the oid in these circumstances?
>
>is it because none of the standards-track mibs send table cells as a
>payload (so nobody thought about them)?
>
>or because nobody uses string indices (and, after all, integer indices
>don't really need decoding)?
>
>maybe manager authors think that the index columns are meaningless
>unless they also display the name of the column (as in a full table
>view), and since they don't have gui space to display the names of the
>index columns, they won't even bother decoding the fields?
>
>if this deficiency in manager design *is* the reason (as i suspect)
>why the mibs i described above have been written in such a twisted,
>standards-violating way, i wonder - have agent writers not been
>communicating with manager writers?  or has there been some hidden
>battle going on that i don't know about? 
>or am i the first person to try to use string indices in a table, and
>report changing cells with a trap?????
>
>or is frank the only author of management software to care whether his
>manager can display traps properly?
>
>maybe people only expect $1000 worth of 'generic' management software
>to work properly on standard published mibs, or near clones?  and
>anyone who wants to talk to a custom agent is expected to write a
>custom manager for it?
>
>
>i feel there must be something i've not been told - please let me in
>on the secret!
>
>thanks for your time
>
>aparimana