[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EOS Row Operations (and other documents)
- To: "EOS WG (E-mail)" <firstname.lastname@example.org>
- Subject: Re: EOS Row Operations (and other documents)
- From: David Waitzman <email@example.com>
- Date: Tue, 27 Mar 2001 10:07:59 -0500
- Delivery-date: Tue, 27 Mar 2001 07:08:38 -0800
- Envelope-to: firstname.lastname@example.org
- Organization: BBN Technologies
With all of this SetRow discussions, I would like to point out a
Please remember that complex TCs that are designed to be reused across
multiple MIBs should be considered as if they are PROTOCOL changes, not
merely "yet another MIB object."
I had this battle years ago with a member of the Gang Of Four; he won
the argument (of course :-) and these kind of complex TCs were
considered as merely MIB issues, not Protocol issues. There was a big
push to avoid "changing the protocol" for the past N years to avoid
backstepping in the standardization process. The practice is though
that they *are* effectively protocol changes, they took lots of time to
be implemented, vendors conflict on how completely they are implemented,
and SNMPv3 was not as clean as it could have been.
My advice: Be realistic in considering what things don't really work.
Don't do half measures to fix them. Do a clean job that is forward
I recently shopped around for some newly written software that needs to
be SNMP managable and was very disappointed at what vendors think is
acceptable to call SNMP managable. Non-atomic SETs. Only V1 and V2C.