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

Re: draft-ietf-eos-snmp-rowops-00.txt

At 5:17 PM -0700 4/28/01, Lauren Heintz wrote:
>It's not the sole purpose.  NotReady is meant to convey that the row
>is not a fully constructed object AND does not qualify to be made active
>AND also that it is subject to automatically timing out (being deleted).
Ok, you caught me. I hadn't actually read the TC. Isn't this timed-out
deletion one of the very things you objected to in RowStatus? I assumed
that you would have removed this behavior.  But since you didn't, and this
behavior pretty much matches the RowStatus NotReady, I withdraw my

>> I don't think that the protocol should make assumptions about default
>> states. If the MIB designer wants a row to default to being active (or
>> inactive), they can specify the initial values using DEFVAL.
>You can provide a DEFVAL for RowState, but I think the only value that
>possibly even makes sense to have in a RowState DEFVAL is Active,
I disagree. For example, I may want to create a new net interface on a
device, and a row must exist before I can create rows in a firewall filter
table. I'd want to create the interface as NotInService, the create
firewall rules, then set the interface active.

>the above behavior in order to allow smaller PDUs to be used to create
>and activate rows.
I think the DEFVAL still allows smaller PDUs, as the RowState would not
have to be specified. But I think the default should be decided on a table
by table basis, not mandated by the protocol.

> This behavior rewards the overwhelmingly typical
>**desire** to create/activate rows in one PDU, if possible, but does
>not penalize anyone when that can't be done.
I'm probably beating a dead horse here, but it does penalize the user when
they want to create a NotReady row, since they must include an extra

>> >3.2.1.  The rowIdentifier
>> >...
>> >      [<foo><op>] [<1.0><op>] [<1.0><op>] [<fum><op>]
>> >
>> What about the case where <fum> AUGMENTS <foo>? :)
>I don't see that as a problem.  That's one reason we
>have to support multiple rowOps in the same PDU.  Am I
>missing your point?
Yes. There is not problem, I was just wondering (somewhat tounge-in-cheek)
if we couldn't also allow :

      [<foo><op>] [<1.0><op>] [<1.0><op>] [<fum><1.0>]

to allow fum to inherit the index from the previous varbind for the case
where fum AUGMENTS foo?