RE: [Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu- 08.txt]

["David B Harrington" <dbharrington@comcast.net>]

> -----Original Message-----
> There are two issues here:
> 
> a) RAQMON MIB
> 

I don't really care much about the RAQMON MIB. If they use this
approach and it is not scalable, you can add more collectors to scale
it.
But it does set a precedent for using tables of notifcations, and
without proper guidelines to others about how and when to use tables
of notifications, this could be a problem in the making.

> 
> 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. 

I'm not sayng that there are not use cases to do this. I am raising
the concern that such an approach using SNMP might not be scalable,
and I don't think we want to appear to be recommending this approach
without a) reviewing real world experience with the scalability of
such an approach, and b) if we consider it a valid approach, what
issues should be considered in the design of future usage of this
approach. Based on my real-world experience, I recommend against using
a purely event-driven approach and recommend a trap-driven-polling
approach.

> In SNMP terms, they needed to implement a notification originator
> application, something the SNMPv3 architecture rightfully allows
> these days. 

And there was only one application generating the notifications? That
would not trigger the scalability issue I am concerned with.

> 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 

Agreed.

> and that (b) dogmas such
> as "you have to do trap-directed polling" seriously restrict
> very valid usage of SNMP technology.

I don't think we should restrict SNMP to trap-directed polling; I
think we should discuss when and how event-driven management with SNMP
is acceptable, and identify the scalability issues of the approach.
Before we publish guidelines that seem to encourage its usage, we need
to be sure the usage doesn't cause problems, and without some guidance
about HOW to use it, and HOW NOT to use it, I think we would be doing
a disservice to the SNMP community.


> 
> I again vote for the i.e. / e.g. errata and then lets move on.

I have also voted for that resolution of the issue.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
>