[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the future of SNMP
[I did not want to respond but I just have to since I see lots of
IMHO stupid arguments.]
B> the bulk data mib was written with ease of compatibility of today's
B> already deployed tools in mind. I chose to avoid things that would
B> require strange software or protocol extensions to be installed on
B> the NMS. all the real meaty bits are on the agent. and really,
B> only a subagent module is needed with the ability to access the
B> faster 'var_' style routines at the agent via direct api calls (in
B> the interest of data snapshot speed).
Fact #1: An AgentX subagent will not work.
B> I suppose I'll have to prove this with an implementation, which I
B> will try to work on and release for the group. you'll see that
B> even using the commandline net-snmp 'snmpset' utility will be
B> sufficient in order to define and initiate a bulk table snapshot
B> (that's all the NMS I tend to use, anyway) and a commandline 'scp'
B> or 'ftp' is all that's needed in order to fetch the data once its
B> been snapped and saved away. finally, if inbound ftp is configured
B> (admittedly the only 'hard' part of the NMS config) then no work
B> needs be done to get to the snapshotted bulk file.
Fact #2: Initiating the bulk transfer is not the same as using it in
an application. Having some encoded data in a file is IMHO
far away from using the data in a management application.
Fact #3: Security mappings between SNMP and FTP will be non-trivial.
I am looking forward to your solution.
B> so, I'm at a loss to understand why this is seen as being anywhere
B> near as much effort to develop and deploy compared to the
B> site-level disruption of drop-shipping a whole new protocol stack
B> on both client and agent (and not just the stack, but an app that
B> uses the stack, as well).
Fact #4: Deploying new protocol operations (if done right) boils down
in most cases to the cost of getting an update of the SNMP
engine and recompiling the agent. The same is usually true
for management applications. In some cases, even existing
applications will be able to use the new bulk transfer
capabilities by simply recomiling them.
B> I propose that even a 10 year old closed-source no-compilers-exist
B> unix box can be an effective NMS in managing the bulk-data agent
B> when using snmpv2/v3. while its absurd to actually do that, I see
B> value in the fact that it _can_ be done, thus showing how minimal
B> the retooling effort would be on the NMS end of things.
Fact #5: A 10 year old closed-source no-compilers-exist unix box will
probably not do much more than some basic RFC 1213 stuff and
we probably do not need protocol extensions for that.
But lets simply agree to disagree.
Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/>