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

Re: What is "SET ROW" / making SETs easier



At 2:56 PM -0800 3/27/01, David Battle wrote:
>I believe that the idea for this feature came from
>Andy Bierman's complaint that one of the reasons
>snmp SET's aren't more widely implemented is the need
>for the agent to accept pieces of a row in any order.
>
I don't think that SET ROW helps implementing row sets very much, because
it wouldn't change the general SNMP rule that all sets must occur "as if
simultaneous." If we want to make SETs easier to implement, we should allow
implementations to specify varbind ordering (see SMING WG), or simply
process them in the order they appear in the PDU, and reject SETs that
don't follow the constraints. Not only would this help for cases where a
SET contains varbinds for multiple tables when there is a dependency
between tables, but would also allow a row that must be nonInService to be
updated to be updated with a single PDU ( status=notInService,
colX=newValue, status=active ).

>At 12:00 PM 3/27/2001, you wrote:
>>Would someone PLEASE explain:
>>  1) what a SETROW operation would do,

I think it could allow more varbinds per PDU via OID compress/suppression.

>>  2) what problems does it solve

it doesn't necessarily solve the problem, but it would certainly help in a
lot of cases.

>>  3) what problems does it create
>>
Hmm... error reporting?  If each row is encoded as a sequence, you have
indicate the row and the column that caused the error.