[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RowStatus questions
> -----Original Message-----
> From: David T. Perkins [mailto:email@example.com]
> Sent: Saturday, May 11, 2002 2:38 AM
> To: Wijnen, Bert (Bert); firstname.lastname@example.org
> Subject: RE: RowStatus questions
> 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.
> >> -----Original Message-----
> >> From: Wes Hardaker [mailto:email@example.com]
> >> Sent: Friday, May 10, 2002 6:40 AM
> >> To: firstname.lastname@example.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) ???
> >> --
> /david t. perkins