RE: the future of SNMP

Glenn writes:

> I have to disagree with the above statement. In a
> *practical* sense many of
> these MIB schemes need special code not only in the
> agent but also in the
> manager. New special code needs to be created for
> each new MIB that gets
> designed to fix some problem. By adding protocol
> operations a general
> solution can be provided that can be implemented
> just once.

the MIB solution that I proposed could be implemented
(at the NMS side) even on a 10 yr antique NMS.  no
significant changes at all, other than the ability to
compile a symbolic mib and do snmp SETs to that mib is
needed.  in fact, even working at the purely numeric
oid level would work.  and, there's no requirement
that the NMS ALSO be the upload file host.  none at
all.  it may well be that the load host and the NMS
are one and the same but nothing will break if that's
not the case.

and I'd be hardpressed to find any reasonable NMS that
couldn't also be configured pretty trivially as an
inbound ftp server.  and if not a server, clearly a
client (for data 'pulls').

the bulk data mib was written with ease of
compatibility of today's already deployed tools in
mind.  I chose to avoid things that would require
strange software or protocol extensions to be
installed on the NMS.  all the real meaty bits are on
the agent.  and really, only a subagent module is
needed with the ability to access the faster 'var_'
style routines at the agent via direct api calls (in
the interest of data snapshot speed).

I suppose I'll have to prove this with an
implementation, which I will try to work on and
release for the group.  you'll see that even using the
commandline net-snmp 'snmpset' utility will be
sufficient in order to define and initiate a bulk
table snapshot (that's all the NMS I tend to use,
anyway)  and a commandline 'scp' or 'ftp' is all
that's needed in order to fetch the data once its been
snapped and saved away.  finally, if inbound ftp is
configured (admittedly the only 'hard' part of the NMS
config) then no work needs be done to get to the
snapshotted bulk file.

so, I'm at a loss to understand why this is seen as
being anywhere near as much effort to develop and
deploy compared to the site-level disruption of
drop-shipping a whole new protocol stack on both
client and agent (and not just the stack, but an app
that uses the stack, as well).  I propose that even a
10 year old closed-source no-compilers-exist unix box
can be an effective NMS in managing the bulk-data
agent when using snmpv2/v3.  while its absurd to
actually do that, I see value in the fact that it
_can_ be done, thus showing how minimal the retooling
effort would be on the NMS end of things.

to me, that's the notion of 'S' in Simple.  sometimes
occam WAS right.


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/