Re: RowStatus questions

Hi Wes,

Not speaking of any preference, but number 4 is acceptable from
an IETF perspective in my opinion.
For instance, the DIFFSERV-MIB has this in its compliance statements:

>    OBJECT diffServDataPathStatus
>    SYNTAX RowStatus { active(1) }
>    WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
>    DESCRIPTION
>       "Support for createAndWait and notInService is not required."

And this was a compromise after the MIB editor did not really
want to have the full implementation of a RowStatus.

Harrie


--On Thursday, May 9, 2002 9:40 PM -0700 Wes Hardaker <[email protected]> 
wrote:

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