Re: Management Requirements

> I have not been considering the case of M>1 messages per event.
> 
> I was writing about the case of E>1 events per message. SNMP limits
> things to at best to one event per message. IPFIX seems to be able to
> batch several events into a single IPFIX message. Of course, there
> are other considerations here, the congestion control of the underlying
> transport and whether a high-level of event notifications are needed
> in the first place. Since this comes up in BEHAVE context, there

I agree with Juergen on mechanics but
think its not entirely an apples to apples comparison.

IPFIX transmits all its state periodically in one go whereas 
SNMP uses notifications to indicate state *has* changed and may not 
provide the entire context of what changed for a reason : that mgmt apps using 
trap a directed polling model will then poll the agent for updated state based
on the type/content of such notifications.

Hence my comment to Ron about the two being more complimentary technologies
than one might think as we've begun to see IPFIX attempt to do more of what SNMP
has done though imo not without solving the problems that trap directed polling
had previously solved.

I'd also note that we provided the following advice to 
mib module authors in RFC 3512:

   No matter which threshold is chosen to govern the
   actual transmission of NOTIFICATION-TYPEs, the idea is to describe an
   aggregated event or related set of events in as few PDUs as possible.
   http://tools.ietf.org/html/rfc3512#section-3.10.2

Mike