why must there be a choice of MIB vs. Protocol?

Wes wrote:

>I think Bert's more specific question was: do you
want >to see further development in the protocol
itself, or >just in the MIBs that are transferred over
the >protocol.


why is this an either/or?

if we want to make progress toward some of our goals
(for example, efficient transfer of bulk data) then
why can't a MIB approach be taken in the short term
while protocol extensions are developed and tested for
a more long-term solution?

a few sessions ago, an associate and I proposed a MIB
solution for efficient bulk transfer of MIB data.  it
required no changes to the snmp protocol and was
somewhat of a hybrid snmp/ftp (or name your favorite
file transfer method) solution.  it seemed to me that
it would be more quickly adopted since there was no
forklift upgrade of either nms or agent.  and, this
hybrid style of management is already in use in
various vendor implementions today (although none are
vendor-independant, which is a problem I wanted to
solve with my EOS proposal).

forcing an either/or situation seems to limit our
advancement in this field.

to get some real-life problems solved short-term, I
think a MIB solution would have been the better
choice.  but that does not diminish Wes's work; as I
see that as a more long-term R&D effort and certainly
worth pursuing.  but don't expect vendors who ship
product in the short-term to want to take on the load
and expense of upgrading, reintegrating, retesting,
recertifying and redocumenting a whole new SNMP stack
(both on agent and nms).  I don't see that happening
any time soon.


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