RE: RowStatus questions

"Harrington, David" <[email protected]>
Newsgroups gmane.ietf.eos
Message-ID <[email protected]>
Hi Wes,

I would recommend using RowStatus as it is. Existing applications have
learned how to use it.

It is my impression as an application developer that having RowStatus to
standardize table handling is far better than what preceded it - chaos.

The main problem is that multiple requests with partial information might
come in any order, before an agent can create the row. You can help solve
the problem by 1) advising application developers in the table
description/entry that it is much easier on the agent if the request
contains all the info and uses createAndGo, 2) defining default values for
anything that could take a default, 3) describing the most efficient
approach to using partial requests to build your table (e.g. relying on
default values), 4) identifying in the mib the minimum number of varbinds
per request an agent implementing your mib should be prepared to support,
and 5) using smaller tables so the number of varbinds needed in a request is
less likely to exceed the processing capacity of agents. 

my $.02
dbh

> -----Original Message-----
> From: Wes Hardaker [mailto:[email protected]]
> Sent: Friday, May 10, 2002 12:40 AM
> To: [email protected]
> Subject: RowStatus questions
> 
> 
> 
> Ok, so lets say you're writing a MIB today (many of us are).  Everyone
> supposedly hates RowStatus, but the primary reason is the
> create-and-wait state.
> 
> So, if you were writing a (standards-based) MIB what would you do
> given todays choices:
> 
> 1) use RowStatus as is, since it's still the currently 
> accepted method.
> 2) Make something up for the MIB (ick).
> 3) use new not-yet standardized ideas (eos-rowops, being one example).
>    [this isn't really an option of course, since I expect my draft to
>     go to proposed before the eos is done debating this issue, and I
>     can't wait (let alone wait for new deployment of protocol code)]
> 4) use RowStatus but in the compliance statements specify that the
>    createAndWait enum value isn't required.
> 5) ???
> 
> -- 
> "The trouble with having an open mind, of course, is that people will
>  insist on coming along and trying to put things in it."   -- 
> Terry Pratchett
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.