| Newsgroups |
gmane.ietf.eos |
| Message-ID |
<[email protected]> |
For our enterprise MIBs we use #4. #4 is also a good way to specify which
items besides the table keys are required at row creation. Keep in mind
that restricting RowStatus to "one-shot" mode, in principle, should only be
done if the protocol can handle the row size. However, I am not sure there
is a toolset out there that looks at the compliance statement.
Sidney Antommarchi
VXi - Systems Engineering
972-301-1258
Wes Hardaker
<wes@hardaker To: [email protected]
s.net> cc:
Sent by: Subject: RowStatus questions
owner-eos@ops
.ietf.org
05/09/2002
11:40 PM
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