[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:
- To: <eos@ops.ietf.org>
- Subject: Re:
- From: Robert Story <rstory@freesnmp.com>
- Date: Sat, 28 Apr 2001 18:23:33 -0400
- Delivery-date: Sat, 28 Apr 2001 15:27:35 -0700
- Envelope-to: eos-data@psg.com
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>? :)