Re: EOS Row Operations (and other documents)

[Robert Story <rstory@freesnmp.com>]

At 1:03 PM -0800 3/30/01, Lauren Heintz wrote:
>> >Conveying Column Indicator
>> >  Can be implicit or explicit
>> >
>> I'm not sure that I believe that it can be implicit.
>
>I agree.
>
>I think column ID needs to be explicit.  The OID names
>of each varbind could be of the form 0.columnSubid (if
>we re-use the existing SetRequest PDU structure).
>
I'd like to see a new PDU structure - I guess I'd like a SetRows (plural)
PDU, as opposed to a simple SetRow.  Using a SEQUENCE for each row would
let this work with and existing SetRequest PDU.

>  Some devices may
>have an older version of a MIB than newer devices and thus support
>different verions of the affected table (lesser or fewer columns,
>or even the same number of columns but logically different ones and
>with or without the same SYNTAX).
>
another good argument for explicit...

>Seems to me it has to pass the SetRow down to whatever subagent(s)
>has registered the affected OID and the subagent has to expand
>the SetRow.
>
I disagree. This would mean changes to AgentX, and I don't want to open
that can of worms.

>  For one thing, even if the master agent does expand
>the SetRow into a conventional Set PDU, then one of the stated
>requirements for even considering SetRow (eases agent implementation)
>isn't realized and the whole reason for inventing it has to
>be reconsidered.
>
I disagree. I think it should also be a goal to ease transition. If the
master agent does the expansion, a lot of existing tables will work with
the change to the protocol engine. Newer tables could use some new API that
would hand in a whole row.

>One possible solution is (?) to use the RESERVED field in the TestSet
>PDU to have a SetRow operation indicator.  Pre-existing AgentX impls
>would ignore that field and would reject the SetRow with predictable
>errors
>
That's a good idea, but I still would rather be able to be compatible with
the existing AgentX spec...