Juergen Schoenwaelder <[email protected]> wrote: > On Thu, Dec 15, 2016 at 04:03:40PM +0100, Martin Bjorklund wrote: > > Hi, > > > > Issue https://github.com/netmod-wg/entity/issues/12 > > > > entConfigChange is useful but maybe covered by netconf-config-change > > notification, or pub/sub. it is also a bad name, since it fires when > > the opstate changes... Need to think about which notifs to define. > > > > Currently we have three notifications: > > > > harwdare-state-change > > hardware-state-oper-enabled > > hardware-state-oper-disabled > > It seems harwdare-state-change is not netconf-config-change. The > harwdare-state-change indicates that the '/hardware-state/component' > list has changed, i.e., operational state has changed not config. (It > is always important to read the descriptions and not to draw wrong > conclusions from the fact the SNMP notification was called > entConfigChange.)
Yes. > > Jason Sterne also made the observation on the ML that maybe pub/sub is > > a better mechanism for these simple notifs. > > Not sure what 'better' means. I assume that generating these specific > notifications can likely be done way more efficiently than doing the > same via a pub/sub interface unless the pub/sub backend code is really > really smart. Yes, I share this concern. I don't think it would be a good idea to remove all notifications and just provide state nodes, and then assume that clients write clever filters in order to get the notificaitons they want. However, in this particular case, the notifications hardware-state-oper-enabled and hardware-state-oper-disabled are simple in the sense that they defined to be generated when a certain node changes its value. > That said, I would not be surprised if application > writers will use pub/sub for everything because the hammer makes > everything look like a nail. We'll see. Specific notifications are often designed to deliver related information, and this might not be to easy to do with a generic solution like pub/sub. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
