RE: RowStatus questions

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Of course.

Bert 

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Saturday, May 11, 2002 2:38 AM
> To: Wijnen, Bert (Bert); eos@ops.ietf.org
> Subject: RE: RowStatus questions
> 
> 
> HI,
> 
> Bert - just to clarify. You really meant all "read-create" columns
> in a row of a table, and not all columns in a row.
> 
> At 02:04 AM 5/11/2002 +0200, Wijnen, Bert (Bert) wrote:
> >I have been promoting option 4 lately.
> >
> >And I would also not have a problem if a MIB developer
> >writes in a DESCRIPTION clause of a table that all the
> >objects/columns for a row must indeed appear in one
> >SNMP SET PDU and I would even accept if you REQUIRED
> >them to be in the sequence as defined in the table.
> >
> >Bert 
> >
> >> -----Original Message-----
> >> From: Wes Hardaker [mailto:wes@hardakers.net]
> >> Sent: Friday, May 10, 2002 6:40 AM
> >> To: eos@ops.ietf.org
> >> 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) ???
> >> 
> >> -- 
> Regards,
> /david t. perkins
>