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

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


Robert Story wrote:
> 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
> objection.

I objected to the timeout beahvior in the NotInService state,
not the NotReady state.  The new TC hasn't been written yet
(it's TBD in the draft).  Hopefully the background text is
sufficient to get the idea across until the TC is completed
(hopefully next draft).
> >> 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.

I suppose there may be some merit to that.  I'll try to work it in
and see what happens.

> > 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
> varbind.

But the penalty you speak of is the same penalty we always incurr
already.  By improving just one part of something, doesn't mean
you're further penalizing the parts you haven't improved (yet).
That just means they still are as inefficient as before!
Anyway, I think we're in overall agreement.

> >> >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?

For a SetRow request, if the instancePart of a rowOp is the
same as any other rowOp in the same PDU, that is intended to
be an error.  One of the design goals is to remove such
ability to confuse implementations (i.e. which rowOp takes
effect if they both set the same objects to different values).

For a RetrieveRow request, they can be the same, though it may
not make sense because it would be more efficient just to
put as many ops in a given rowOp as needed.  In other words,
if you do have a GetRow request with one rowOp:

  1.  GetRow (rowId1:foo.row1, op1A=fooInt, op1B=fooUnsigned32)

You could also do the same things by using two rowOps instead:

  2.  GetRow (rowId1=foo:row1, op1A=fooInt, rowId2=foo:row1,

or using inheritance:

  3.  GetRow (rowId1=foo:row1, op1A=fooInt, rowId2=1.0:row1,

and using your suggestion:

  4.  GetRow (rowId1=foo.row1, op1A=fooInt, rowId2=1.0:1.0,

Those are all logically identical, but these are the
most efficient 1 (best), 4, 3, 2

So by allowing inheritance at the instancePart level, we only
encourage bad use in case of RetrieveRow, or errors in the case
of any SetRow.  Besides I think the 1.0 cannot be distinguished
from actual instance values that may be in a vb.value (whereas
the 1.0 values in the vb.name can always be distinguished
from valid MIB objects).