Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Oct 17, 2013 at 05:55:13PM +0900, Keiichi SHIMA wrote:
> Hello,
> 
> On 2013/10/15, at 23:42, Joe Marcus Clarke <[e-mail]> wrote:
> 
> > In terms of the new notifications, why enumerate all states as notifications?  My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object).  It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future.
> 
> Ah, I misunderstood your comment.  I did the change actually.
> 
> Consolidating all the notification messages (maybe we will have two eventually, one is for a per VM notification, and the other is for a bulk notification) may be reasonable.
> 
> # we can even unify a per vm notification and a bulk notification, but maybe it is not a good idea?
> 
> If there is no strong opinion for not to unify the notification messages, then we will do the change and resubmit an updated version before the cut-off date (next Monday).
> 

I had this design (generic state change notifications) in my original
MIB module but then I got convinced by Michael that many real-world
applications prefer to have the notification type be specific so that
they can react to the different state changes by simply looking at the
notification type (without having to look into the notification
payload). This is why we got to the current design.

We should be careful here and take care to produce something that
existing notification receivers find 'easy' to process. The number of
states we have should be small and ideally not change over time, so
the implementation costs on the agent side likely are not big.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>