Re: developing an application to return snmp information

Not a problem. I thought that I did CC the list.

On Thu, May 1, 2008 at 3:45 PM, Dave Shield <D.T.Shield@liverpool.ac.uk> wrote:
> [ First - *please* don't mail me privately, without copying
> any responses to the mailing list. I don't have the time
> or inclination to offer private, unpaid, SNMP consultancy.
> Keep discussions to the list, where others can both learn
> and offer advice. Thanks. ]
>
>
> 2008/4/30 ntwrkd <ntwrkd@gmail.com>:
>
> > Hey David,
> > Thank you for these helpful tips.
> > I have one question about your response:
> >
> > > The simplest way would probably be to use the "extend" mechanism
> > > to run a suitable command, which would report the information you
> > > are interested in.
> > > That would allow you to retrieve this information, without having
> > > to define and implement a MIB.
> >
> > If I can extend the agent without redefining the MIB, why would I need
> > to have a MIB at all?
>
> If you are using the extend (or exec) mechanisms, then the results
> are structured to match the MIB definitions for these two formats.
> In particular, all output is reported as string values (even if they are
> actually numbers)
> The onus is on your client-side tools to interpret this standard
> structure in a way that is appropriate for the data that you are
> working with.
>
> If the "client side tool" is a person, then this isn't typically a problem,
> since such applications are incredibly sophisticated :-)
> But if you want to do automated processing of the results, then
> this standard framework can sometimes prove an obstacle.
> That tends to be where defining and implementing a more
> dedicated MIB can be helpful, since the structure can more closely
> match the characteristics of the data.
>
>
>
> > Are MIB's intended to work with extending the agent?
>
> MIBs essentially describe the information being reported, in a standard
> manner. They act as a design document for both the agent and the
> client tools, and help ensure that the two sides agree about what
> information is actually being worked with.
>
>
>
> > Or to create a MIB, my application would have to have a copy of the
> > default IETF OID tree with my own extensions included?
>
> No - your extensions would typically be defined as a (more-or-less)
> self-contained MIB. Your application would only need access to
> those MIB definitions that were relevant to what it actually needs
> to do - it can safely ignore anything else.
>
> Note that this "access to MIB definitions" doesn't have to be the
> actual MIB file. It's equally as valid to have the relevant MIB OIDs
> hard-wired into the application code. The MIB file definitions can be
> used at the design stage (to know which OIDs to work with),
> as well as/instead of at run time.
>
> Dave
>

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757...un.com/javaone
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders