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

[Keiichi SHIMA <[e-mail]>]

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 <[e-mail]>
Research Laboratory, IIJ Innovation Institute, Inc <[e-mail]>



On 2013/10/17, at 18:17, Juergen Schoenwaelder <[e-mail]> 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 <[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/>