On Thu, Oct 17, 2013 at 05:55:13PM +0900, Keiichi SHIMA wrote: > Hello, > > On 2013/10/15, at 23:42, Joe Marcus Clarke <[email protected]> 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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
