Re: the future of SNMP

--- Wes Hardaker <[email protected]> wrote:
> 
> I'm confused at why there is an argument over what
> the NMS could
> support.  That is hardly what I think needs to be
> optimized for in
> this case (certainly it's impacted, but I'm much
> more concerned about
> the 10000 agents that it's speaking with than the 1
> NMS box).

I guess its where your job lies.  if you're an NMS
vendor, you'd probably prefer NOT to make major
changes to your existing product line to make use of
the new bulk data MIB extensions.  simply shipping the
new asn.1 MIB and -maybe- a quickie graphical plugin
app is all that's needed.  and for sites that have a
lot of NMSs deployed, its a headache to have to revamp
them all.  and if a site is running some trusty crusty
old NMS that has been EOLd, there's no upgrade path at
all if they want to use the extended protocols
approach.  they must junk their existing NMS and go
with something new.  this isn't always good, business-
and otherwise

for equipment vendors, I can see that they care more
about the effect on their codebase (the agent) and not
as much about the NMS end of things.  true, for both
the protocol and the MIB approaches, you'll need to
install new agent code on the managed objects.  you
could argue that an agent upgrade is an agent upgrade
(and both are disruptive) so its a wash whether you go
full tilt and put a new (second) stack on the agent or
just an additional subagent plugin.  so there's no
clear argument for either approach at the agent side
of things, for either of our approaches.

but there's clearly a win on the NMS side of things. 
and for NMS, I also count scripts that people write to
get short to-the-point jobs done.  in that case, no
new stack is needed for the bulk-data-mib approach. 
but for the OO protocol approach, a lot more changes
are needed at the NMS side, correct?

overall, the amount of upgrade and reconfig needed for
one approach over the other IS an important factor for
many operations shops.  that's what I was trying to be
very sensitive to in my design.  having less to
upgrade, document, retest and recertify means less to
break and a quicker time-to-acceptance to gain the new
functionality.

admittedly the bulk-data-mib solves only the bulk data
problem and the OO protocol approach will hopefully
solve a wider range of problems.  but some sites might
only feel the need for an efficient bulk data
solution; in which case the bulk-data-mib may be all
the upgrade they want to sign on for.



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