RE: The datamodel in Notification Draft

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

-- copied from below --

> 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.

So, you're saying that if using a connection oriented protocol, things
will not scale. Thus continue to use syslog/UDP. 
The syslog WG has RFC3195, draft on syslog/TLS, and there had been some
discussions on syslog/SSH. As Balazs says in one of his responses there
is also the ISMS work. I don't understand how this is a problem for
NETCONF and not for others. 



> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, May 18, 2006 6:08 AM
> To: Balazs Lengyel
> Cc: Netconf (E-mail)
> Subject: Re: The datamodel in Notification Draft
> 
> 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/>
> 

--
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/>