Subject: RE: Why are we doing netconf?

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 29 Mar 2006 10:08:33 -0500

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:[email-masked]] 
Sent: Wednesday, March 29, 2006 9:16 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]; [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Mar 2006 18:23:42 +0200

> - Netconf content (without mapping )

What are the classes you have in mind? Can you elaborate a bit more?

> - Predictable content

What is predictable content?

> - reliable delivery (or ability to detect when things go wrong)

Why is that a requirement? What is this good for in operational
environments?

> configuration snippets, etc)

Is "configuration snippets" and event type? Is logs == syslog
messages?

> - XML encoding (not a big driver, but certainly a major industry

If XML encoding is a requirement, is then not structured content
superfluous? Since netconf content is XML, is even the XML requirement
superfluous?

I am asking these questions simply because I want to understand what
people mean when they throw in some terms.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Mar 2006 15:05:07 -0800

> - XML encoding (not a big driver, but certainly a major industry

Why are all these features important?
The agent people in the WG think there is too much
complexity in your proposal.  The NMS people think
there is not enough features in any of the simple
proposals.

We are deadlocked.
It is going to take detailed technical justifications
to move either side at this point.  Not a bullet list.

Andy