RE: RowStatus questions
"Wijnen, Bert (Bert)" <[email protected]>
| Newsgroups | gmane.ietf.eos |
|---|---|
| Message-ID | <A451D5E6F15FD211BABC0008C7FAD7BC0DE0BFF0@nl0006exch003u.nl.lucent.com> |
Of course. Bert > -----Original Message----- > From: David T. Perkins [mailto:[email protected]] > Sent: Saturday, May 11, 2002 2:38 AM > To: Wijnen, Bert (Bert); [email protected] > 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:[email protected]] > >> Sent: Friday, May 10, 2002 6: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) ??? > >> > >> -- > Regards, > /david t. perkins >