Hello Juergen and Joe, >> 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.
I think this is a good point. Joe, do you have any strong objection for the above approach? If you can live with either ways, then we will keep the current style. --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> On 2013/10/17, at 18:17, Juergen Schoenwaelder <[email protected]> wrote: > 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
