[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trap design - theory vs practice



At 11:08 AM 4/8/2004, Randy Presuhn wrote:

I'm not saying this.
I was never here. :-)
It may or may not be true that the NMS developers
employed by the same company as me are clueless
idiots who can't code their way out of a wet paper bag.

It may or may not be true that I've had long email threads
with alleged SW designers on the importance of the
ability to extract index components from a varbind.
There may or may not be some reason why these same
alleged SW designers cannot reuse their own 'getnext'
code for this purpose, which obviously must extract
the index components in order to process replies
for getnext requests.

I can only imagine what kind of stupid code tricks 
will emerge in netconf applications, given that the
same idiots will probably end up writing our XML
applications for us.

Andy


>Hi -
>
>> From: "David T. Perkins" <dperkins@dsperkins.com>
>> To: <mreview@ops.ietf.org>
>> Sent: Wednesday, April 07, 2004 11:09 PM
>> Subject: Fwd: trap design - theory vs practice
>...
>> Below is a message that describes the current state of the art.
>> It's sad.
>
>Indeed.
>
>> >Date: Thu, 08 Apr 2004 01:37:18 +0100
>> >From: aparimana <aparimana@camart.co.uk>
>...
>> >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!)
>
>I know my former employer's bilingual CMIP/SNMP management
>system could pull them apart, (though it's been in mothballs for over
>a decade) and I know my most recent employer had the software to
>do it, though I don't know what they did with that code.  The "gotcha"
>of course is that the management system needs access to
>the relevant parts of the MIB module in some form in order to
>parse the OID.  It's hardly rocket science, which makes it even more
>sad that any software would be out there that wouldn't handle it.
>
>(It would have been better if the rules for constructing
>object instance identifiers resulted in self-describing values,
>but hey, that would have been CMIP.  :-)
>
>> >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'!
>
>At least one commercial SNMP toolkit did not have this problem.
>Words like "brain-damaged" come to mind regarding the situation
>the writer describes.
>
>> >surely designing an agent's mib this way is madness:
>...
>
>Agreed.
>
>Randy