MIDCOM MIB suggestions for addressing the notification requirements

Hi,

When working on the requirements for MIDCOM, I observed that the 
notification requirement always seemed slightly misplaced.  Many of the 
motivations for notification had to do with monitoring or traditional 
network management of some kind which was orthogonal to the core open 
and close pinholes and bindings functionality in the semantics 
document.  What really convinced me that the notification function was 
separate was when I started to imagine all the other things that might 
want to be decoupled from the core MIDCOM protocol and still find out 
about MIDCOM-related notifications.

To that end, I propose that we allow the MIDCOM notification to be 
decoupled from the core MIDCOM MIB, and that we reuse an existing MIB 
to facilitate the notifications.  Specifically, we can use the Event 
MIB (RFC 2981) to set notifications for interesting events that occur 
with other MIB variables.

For example, the simplest use of the Event MIB would monitor the 
Application Management MIB (RFC 2564) to receive notifications if the 
middlebox controller application terminates unexpectedly or is going 
down for maintenance.

In another example, the Event MIB would monitor the Meter MIB (RFC 
2720-- which provides a MIB for the real-time traffic of individual 
network flows) to see if certain flows exceed a threshold (or when the 
traffic flow drops to zero for a period of time).

Finally, the Event MIB could monitor the the Host Resources MIB (RFC 
1514) to watch for CPU  or memory consumption thresholds.

All of this type of monitoring is much closer to the traditional uses 
of SNMP than the rest of the MIB, and so is much more likely to be 
useful by other more traditional SNMP monitoring applications.  It 
would be a shame to reinvent a MIDCOM-specific notification mechanism, 
when a more general one is already in use that is likely to be more 
appropriate for many of its consumers.

thanks,
-rohan