[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu- 08.txt]
On Fri, Jan 14, 2005 at 05:09:20PM -0500, David B Harrington wrote:
> However...
>
> I have a concern over whether tables full of accessible-for-notify
> objects obscures the fundamental trap-directed-polling philosophy of
> SNMP. I think doing this is bad practice.
There are two issues here:
a) RAQMON MIB
Personally, I think the RAQMON MIB looks odd. My main critique is
that the encoding is totally inefficient using SNMP and right now
the MIB says that basically all columns are optional so that you
can work around the inefficiency of the encoding by sending short
varbind lists because the full record would just be way too big
due to the repeated noisy OID stuff. The TCP transport looks much
simpler and the current text which talks about congestion issues
is not at all convincing if you ask me. But that's just my personal
opinion and the RMON WG has to sort this out.
b) pure notification table
Saying "we do trap-directed polling and we do not believe
there is a use-case where you rightfully want to do something
else" is IMHO stubborn. Some years ago, I was consulting with
a company working on a piece of software that was taking data
from mobile devices testing cellular networks and feeding the
stuff in the management system used to run the cellular network,
a OSI/CMIP based system. The management system was largely
event-driven using the X.7xx and provided an interface which
allows to feed SNMP traps into the system which would then
convert stuff into the CMIP internal event records. So the
problem to solve was basically to generate an SNMP notification
stream running over a local LAN into the real management system.
In SNMP terms, they needed to implement a notification originator
application, something the SNMPv3 architecture rightfully allows
these days. I think this is a clear example demonstrating that
(a) the SNMPv3 architecture got it right to split managers and
agents into smaller functional pieces and that (b) dogmas such
as "you have to do trap-directed polling" seriously restrict
very valid usage of SNMP technology.
I again vote for the i.e. / e.g. errata and then lets move on.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany