[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOS WG Status




>>>>> snmp  writes:

snmp> bringing this to a concrete example (that of bulk-data
snmp> retrieval, of which I have a mib submission), I found that by
snmp> leveraging existing protocols (scp, ftp, tftp, etc) and existing
snmp> compression (gzip, bzip, etc), that no new PDU types were needed
snmp> in order to accomplish the end goal.  zero code on the NMS has
snmp> to be rev'd.  this is A Good Thing and helps control cost of
snmp> deployment as well as reduce time to market and possible bug
snmp> count.  yeah, real world issues..

Assume an SNMP application that current does only speak SNMP. Getting
faster access to MIB objects via other protocols requires to add at
least one of (scp, ftp, tftp, etc), one of (gzip, bzip, etc) plus I
need to potentially worry about security issues (e.g. firewall
configs) and different key management domains. Whether something is
cheaper really depends on what your assumptions are.

I have applications that retrieve and process MIB variables (they
sometimes also write MIB variables but that is not the point here ;-)
by using compiler generate stubs and I want to be able to take
advantage of a faster bulk transfer mechanism by simply regenerating
stubs and relinking the applications. For me, this seems to be much
simpler to accomplish if I stay within a single protocol rather than
having mixtures of protocols with varying error code models,
administrative models, ...

In my view, the big investment is in the applications and the agents
and my prime goal is to be able to make them faster without having to
change them nor do I want to add any administrative complexity for
those who finally use all this. And actually, some of the proposed
protocol enhancements are just a few screenfull of source code changes
and much smaller compared to adding at least one of (scp, ftp, tftp,
etc) and at least one of (gzip, bzip, etc).

Note that I do understand and accept that there are very different
implementations and requirements and so I do not expect everyone to
share mine - but this does not make them wrong.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>