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 <[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.
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: +1 (919) 392-2867 c i s c o S y s t e m s
Email: [email protected]
----------------------------------------------------------------------------
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
