[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EOS Row Operations (and other documents)
- To: Lauren Heintz <email@example.com>
- Subject: Re: EOS Row Operations (and other documents)
- From: Robert Story <firstname.lastname@example.org>
- Date: Thu, 5 Apr 2001 17:35:15 -0400
- Cc: "EOS WG (E-mail)" <email@example.com>
- Delivery-date: Fri, 06 Apr 2001 12:35:19 -0700
- Envelope-to: firstname.lastname@example.org
At 3:41 PM -0800 3/30/01, Lauren Heintz wrote:
>- If SetRow is one PDU and only has creation
>OR modification semantics,
I think the benefit of SetRow is primarily OID compression, and
creation/modification/deletion is still a function of each individual table.
>you have to continue using RowStatus-like objects
>in future MIBs so you can create and delete rows
>and do so safely in multi-mgr scenarios.
I think there will always be a need for RowStatus-like objects. Even if we
move creation/deletion into the protocol level, the active and notInService
states are useful in many cases. And agents with tight memory constraints
will still need createAndWait for tables with lots of rows.
>as we're wrapping the PDU in the old SET, why not wrap it
>in the old AgentX TestSet as well (i.e. stuff an
>operator in the RESERVED field).
>(and don't force re-spins of either rfc1905 or AgentX???).
I would think that changing the use of a RESERVED field would require a