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

[Joe Marcus Clarke <[e-mail]>]

On 10/17/13 5:17 AM, Juergen Schoenwaelder 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.

Okay.  Good to know the back story.  I know we have precedence for the 
consolidated approach as well.  If we feel that the states won't change, 
then listing them out shouldn't be a scalability issue.

Joe

>
> /js
>


-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: [phone]         c i s c o  S y s t e m s
Email: [e-mail]

----------------------------------------------------------------------------