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


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.

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

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