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

RE: proposed row ops requirements


Sharon> <Juergen> Question: What happens if I implement a command
Sharon> responder which supports all row new operations plus the RFC
Sharon> 1905 operations without the set operation? The motivation for
Sharon> doing this is that sets on arbitrary combinations of objects
Sharon> is way to expensive. If we have row operations, then I could
Sharon> get away with doing sets on arbitrary objects. Well, I could
Sharon> allow sets on those objects that map to row operations. Does
Sharon> it make sense to allow for this, e.g. by returning a suitable
Sharon> error code on all sets that do not map to row operations?
Sharon> </Juergen>

Sharon> Is it traditional sets people have a problem with or the
Sharon> entire RowStatus create/delete situation?  If we are talking
Sharon> about simple sets that just change a to b, then I think we
Sharon> should be able to require support of these operations.

Some sets are simple, others not. Where do you draw the line?

RowStatus is a specific example of a construct which is not
simple. But there are other MIB objects where it would make a real
difference if compiler generated code can already reject stuff which
is in some sense incomplete or too complex to implement.

Well, I'm still not sure how big this problem is once we eliminate
RowStatus.  If we do decide to allow set row operations without
sets, then I think we'll need to give a bit of thought how best to
do this - views, snmpXproto MIB, text in RFC, etc.

The current protocol operations require me to set arbitrary
combinations of potentially interrelated objects in a quasi atomic
way. This is expensive to implement if you take it serious and I fail
to see the real benefit of actually allowing this. By just not
supporting the set operation and doing row operations instead which
cut the unlimited flexibility to some extend, my coding efforts come
down to something more reasonable.

Sharon> This would avoid having people falling down the slippery slope
Sharon> and perhaps deciding they don't need to support traditional
Sharon> gets either.  If that starts happening then we have lost our
Sharon> goal of co-existence with SNMPv3.

Whatever this group decides to do: We must get a major reduction of
the coding costs on the manager and agent side - otherwise SNMP will
sooner rather than later run out of business. And in order to reduce
costs, we must cut some flexibility and we must propagate the EOS
changes all the way down to the method routines. If we stop at the
sub-agent interface, than the win is IMHO not worth the effort.  If we
do not do the things that must be done because of fears that people
will not understand or misuse things, than this project is IMHO also
on a very slippery slope.

My key EOS requirements are:

(a) Make SNMP efficient so that retrieving a table with a few hundred
    entries is at least as fast as retrieving the same information via
    other channels (e.g. FTP or CLI).

(b) Make the costs for implementing writable objects at least as cheap
    as implementing a CLI command or a Web interface.

Lets do whatever is needed to achieve (a) and (b) and lets not get
blocked by any religious arguments or some fear that people will find
a way to mis-understand or mis-use the technology. (They will do
anyway. ;-)


Those are all great goals.  

No, I'm not getting religious.  But, last I checked we were not working 
on SNMPv4.  We do have a requirement to play nicely with SNMPv3 managers.

Those of us who are manager types do have to worry about people
and misusing things, since we tend to have to manage it all when it is done.
Consistency and predictability is mainly what we ask.