Re: The datamodel in Notification Draft

[Andy Bierman <ietf@andybierman.com>]

Hector Trevino (htrevino) wrote:
>  
> -- 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. 


Netconf has a <hello> exchange. So does beep.
Callhome is under-specified and not actually
coupled to notifications anyway.

If you wanted to secure the notification stream,
and you are starting with syslog and/or snmp notifications,
then it is not a foregone conclusion that you would
end up with verbose XML encoding and the netconf subscription
approach in the current draft.  It may make more sense to
simply secure the existing protocol, whether that is
syslog/TLS, syslog/SSH, or snmp/ISMS.


Andy



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


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