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

RE: proposed row ops requirements


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

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

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