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

On Thu, May 1, 2008 at 3:45 PM, Dave Shield <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>
> > 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;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to