RE: Why are we doing netconf?

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

This may be a good list to start a discussion about Netconf
notifications, but are all these requirements at the same level of
priority? Maybe there is a sub-class of higher priority requirements
that can be met with a simpler protocol? 

Dan


 
 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Wednesday, March 29, 2006 5:09 PM
> To: netconf@ops.ietf.org
> Subject: RE: Why are we doing netconf?
> 
> Here are some of the requirements . 
> 
> - Netconf content (without mapping )
> - Filtering
> - Subscription
> - Event classification
> - Structured content
> - Predictable content
> - reliable delivery (or ability to detect when things go wrong)
> - event replay
> - Ability to support different types of events (alarms, logs, 
> configuration snippets, etc)
> - XML encoding (not a big driver, but certainly a major industry
> direction)
> 
> The thing I struggle with in syslog is the well-deployed 
> syslog versus the new stuff we designed. I think some of the 
> changes made recently to add new features on top of legacy 
> (or that is at least my
> interpretation) will help compared to the original plan, but 
> I worry that if we change syslog too much we lose any 
> benefits of using an existing solution. We then end up with a 
> new protocol that we still call syslog for sentimental 
> reasons, but not one that integrates well with either legacy 
> syslog or other management functions being supported by 
> solutions like Netconf.
> 
> The same applies to trying to modify SNMP to do this as well. 
> 
> Sharon
> 
> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Wednesday, March 29, 2006 9:16 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]; netconf@ops.ietf.org
> Subject: RE: Why are we doing netconf?
> 
> 
> Sharon, 
> 
> > <Rainer>
> > *If* the primary motivation to include notifications is to replace 
> > syslog, I think a shared effort with the syslog community would be 
> > benefitial. </Rainer>
> > 
> > That isn't our primary motivation. It is just that some
> > people feel that
> > some of the requirements can be met by this existing 
> > solution, which is
> > why it comes up.
> 
> From following the list (but sometimes briefly), I have to 
> admit that I
> do not have a clear impression on what the primary motivation 
> is and why
> a separate event logging protocol is needed. I think it would help
> immensely if there would be description of what is intended and why
> syslog can not do the job. That would also help focus the document on
> these topics. Besides, it might be easy to modify syslog to solve
> issues...
> 
> I am aware that there is a requirements/motivation discussion. I think
> this discussion is useful for the reasons outlined above.
> 
> Rainer
> 
> 
> --
> 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/>