Balazs Lengyel wrote:
Andy Bierman wrote:Balazs Lengyel wrote:Hello, Some comments to Andy's model:We need the concept of "Ongoing Notification Session" (subscription in the draft) We need this as we do not want to open a new session for each notification for each target. We need to store the existing sessionId and reuse it.IMO, there isn't any session-based notification system that makes sense. We should not reinvent UDP based notification architecture with some hack to get around the overhead of sessions. The notion of a session that exists even if the other peer in the session does not exist -- is extremely broken. Is this what you mean by "ongoing session"?NO. But if the other end does not exists (callHome) the node tries to set up a session to it. If the peer really doesn't exist the session setup fails the notification will not be sent. But if the peer exists just the session between the manager and the agent is missing the agent should be able to rebuild it.This is significantly more complex than the traditional NV-configured fire-and-forget UDP-based notification systems. If any part of the "use-UDP-instead-of-TCP when the network is unstable" doctrine is still true, then it is for fault notifications.Currently we have 3 transport SSH, BEEP and SOAP so UDP would be something new. Do you suggest we should go for UDP or what is your proposal ?
No -- you are missing my point. I am not convinced that netconf is an appropriate protocol to replace the functionality of syslog. I would just use syslog if I wanted a notification system that scales. If I wanted a nice-to-have feature to make NMS netconf dev-work a little easier, I would consider using netconf notifications.
For mixed notification sessions we anyway need to maintain the session. JURGEN! Could you tell us how ISMS is solving the session based security?As I understand they also decided to have proper security you need to maintain sessions.Balazs
Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>