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

Re:



Hi,

Thanks for your comments!

Robert Story wrote:
> 
> At 10:26 AM -0700 4/19/01, Lauren Heintz wrote:
> >3.1.  RowState
> >...
> >   In addition, unlike RowStatus, it is permissible to explicitly set
> >   RowState objects to the NotReady state as a crude means of allowing
> >   traditional SetRequests to delete the row.
> >
> If this is the sole purpose of the NotReady state, then I think at the very
> least we should rename it to avoid confusion.

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).
NotInService is meant to convey the row represents a fully instantiated
object whose state is inactive and which may not timeout (as per
RowState
TC semantics).  In any case, I don't have a problem with changing the
TC/state names.  One of the known issues suggests an alternative:
RowLock (Undefined, Unlocked, Locked), but I think that has worse
problems.

Or how about: RowState (Undefined, Inactive, Active)?

Other specific suggestions are welcome!

> 
> >   in the request. A CreateRow request by convention contains an
> >   implicit operand (i.e. varbind) to set a corresponding RowState
> >   object (if any) to the Active value.
> >
> 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,
since the other two (NotInService, NotReady) would be hints that would
be guaranteed to be ignored because of the fundamental semantics that
RowState MUST abide by.  So, if Active is the only possibly useful value
as a DEFVAL, that means it can be implicit, which is why I've proposed
the above behavior in order to allow smaller PDUs to be used to create
and activate rows.  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.  Also, the protocol is not
providing a defval simply because we allow an implicit RowState=active
in a CreateRow request.  The user controls whether it's there or not
and,
thus, it's the user that's providing the defval, if you want to call it
that.

> >3.2.1.  The rowIdentifier
> >...
> >   In this example, a simplified notation is used to help illustrate how
> >   a rowOp (the two middle ones in this case) uses the inheritance OID
> >   to minimize PDU size.  This example shows four rowOps, each comprised
> >   of one rowIdentifier and one operand (op):
> >
> >      [<foo><op>] [<1.0><op>] [<1.0><op>] [<fum><op>]
> >
> >   The following is logically identical to the preceding example (though
> >   it forms a larger PDU):
> >
> >      [<foo><op>] [<foo><op>] [<foo><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?

Thanks, Lauren