RE: Why are we doing netconf?

["Sharon Chisholm" <schishol@nortel.com>]

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