Re: Why are we doing netconf?

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Hi, 

from the syslog guy's perspective:

*If* the primary motivation to include notifications is to replace
syslog, I think a shared effort with the syslog community would be
benefitial.

A root problem in syslog is the lack of interest. (Partly) following the
dicsussions on this list here, the same problem seems to resurface for
netconf notifications. I have come to the conclusion that too few
people/organizations have deep interest in system logging and that this
prevents (at least hinders) any serious effort to standardize an event
logging system (essentially, this is what snmp, syslog and eventually
netconf notifications is basically about).

With that said: the lack of a common data model is the primary problem
in syslog. I guess everybody here knows the negative effects of this
missing standardization. For another description, you might have a look
at my paper:

http://www.monitorware.com/en/workinprogress/nature-of-syslog-data.php

This primary problem has not been addressed so far. The syslog-sec WG
was not (and is not) able to do this, because message content is beyond
the charter. This is probably good, because the WG is progressing slowly
enough even with its limited charter. The only thing we "managed" (no
IDs are final, so we can't be sure we actually managed anything...) is
to include the STRUCTURED-DATA (SD) concept. SD is the primary extension
mechanism and hoped to be immensely useful when (if) it comes to content
standardization.

An effort to standardize a data model for logging messages would
definitely be useful, be it for syslog or netconf. I think such a model
must not necessarily be bound to a specific protocol. But there could
(must?) be different models for different use cases (e.g. traffic
reporting, firewalls, config changes, hardware failure reports...).
*This* would be immensely useful to the industry. If that standardized
event would be carried by syslog or netconf is actually of less interest
(at least in my point of view).

Please note that an important motivation for the current series of
syslog IDs was to make syslog transport-independent. You might want to
review a presentation of the early ideas:
   http://www.syslog.cc/ietf/presentat/syslog-protocol-03/index.html

It is partly outdated, but the transport-independence is still described
correctly. This slide is probably the most important one:
   http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img6.html

Given this design, syslog could use netconf as a transport. I know this
is different from what the current notification draft describes, but I
would like to mention it.

One way of integrating syslog and netconf could be that netconf
describes the data model and actions that are needed to

- set up a syslog subscription
- filter/specify the events to be sent
- cancel the syslog subscription
- *understand* the event message content

Once the subscription is setup, syslog messages could travel via RFC
3195(bis) or any other upcoming transport. This would also solve the
issue of an endless RPC, because the actual asynchronous notification
happens via a protocol that is designed to handle them. Plus, it would
solve the issue of the simplex syslog nature, allowing the syslog client
and server to exchange parameters via a separate netconf connection.

The problem with this approach is that it is somewhat like (non-passive)
FTP with a control and data connection. There are a lot of security
implications in this design.

If netconf does notifications, I think specifying a data model is the
top priority. It isn't sufficient to just deliver an event. Its content
and meaning must be understandable. If netconf just specifies a
transport, it will end up with another transmission mode for event
messages. I wouldn't see any advantage over current syslog in this case.

And: please do not underestimate the problems that come along with
insufficient interest in the topic. To limited review of IDs is an issue
I know very well from the syslog WG. If you read the syslog archives,
you will also find that there are few regulars. People come and go.
Depending on who's active when, design choices change. We have more than
once run in cycles just because active participants disappeared for a
while whereas past participants entered again. This caused a constant
shift in decision. It was the primary reason that the work, when thought
to be completed, was once again revamped and nearly put to a stop. It is
quite questionable if the syslog WG will succeed this year. If not, it
will be an official failure and no syslog RFC will appear (which of
course could be a motivation to do it in netconf). I doubt it is useful
to split ressources in an area where already very few people express
interest in.

Rainer Gerhards

> -----Original Message-----
> From: 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of David Harrington
> Sent: Tuesday, March 28, 2006 8:26 PM
> To: 'Netconf (E-mail)'
> Subject: Why are we doing netconf?
> 
> Hi,
> 
> I would like a better understasnding of why we are doing
> notifications. I am struck by what appears to me to be two very
> different drivers for netconf, and the "why are we doing
> notifications?" question relates to these different motivations.
> 
> I have suggested that the O&M and Security communities should work at
> establishing a strategic vision about converging aspects of the
> various NM protocols and NM security solutions. If this is a path
> worth taking, it should be a deliberate decision to do so because
> there are some real problems associated with a convergence approach.
> 
> For this reason, I would like to understand what we are trying to
> achieve with netconf and the current proposal for notifications, to
> determine if the goals are compatible.
> 
> If the purpose of netconf is to provide a machine-friendly,
> standardized protocol to eliminate the need for screen scraping CLI
> expect scripts, I am not convinced we need notifications in the
> netconf protocol. I think the netconf WG has done a reasonably good
> job of standardizing the operations, but to achieve the goals, we also
> need to improve the parseability of the data that now needs to be
> screen scraped. The parseability of the data contained in the
> responses coming back must be addressed. If vendors simply take their
> existing screens of data and surround them with <cli></cli> tags, then
> I think we've failed to eliminate the screen-scraping problem, and
> other problems identified by operators at the IAB NM workshop:
> 
>    -  Some command line interfaces lack a common data model.  It is
> very
>       well possible that the same command on different devices, even
>       from the same vendor, behaves differently.
> 
>    -  The command line interface is primarily targeted to humans which
>       can adapt to minor syntax and format changes easily.  Using
>       command line interfaces as a programmatic interface is
> troublesome
>       because of parsing complexities.
> 
>    -  Command line interfaces often lack proper version control for
> the
>       syntax and the semantics.  It is therefore time consuming and
>       error prone to maintain programs or scripts that interface with
>       different versions of a command line interface.
> 
>    -  Since command line interfaces are proprietary, they can not be
>       used efficiently to automate processes in an environment with a
>       heterogenous set of devices.
> 
>    -  The access control facilities, if present at all, are often
> ad-hoc
>       and sometimes insufficient.
> 
> Netconf does not seem to resolve these operational disadvantages of
> the CLI, and notifications aren't even mentioned as a problem to be
> solved.
> 
> If the purpose of netconf is to standardzie existing practice, and
> existing practice is defined as screen scraping CLI expect scripts
> plus syslog notifications, then I question whether we need to include
> syslog notifications in netconf; syslog works well in its special
> niche, and really doesn't need to be added to netconf.
> 
> The Syslog (-security) WG has been working to standardize the message
> header format. The syslog community has not reached consensus on the
> need to standard message content, except to add a structured data
> component. The WG had difficulty even reaching agreement on
> standardizing their message header format beyond starting the message
> with <PRI>. I do not believe that netconf would be more successful at
> standardizing syslog content than the syslog community, so I do not
> believe that standardizing syslog message content should be a
> justification for adding notifications to netconf, without a long
> discussion about the feasibility of accomplishing this goal. I think
> the standardization of syslog belongs in a (O&M) syslog WG, not the
> netconf WG (and not the syslog security WG).
> 
> If the purpose of netconf is to assimilate the functionality of older
> protocols like syslog and SNMP - to integrate them into a collective
> netconf structure, and to eventually replace the old protocols with a
> new general purpose management protocol minus the known problems, then
> netconf has a higher bar to meet in its design requirements than have
> been acknowledged. SNMPv3 is complex because it needed to deal with
> security issues and troubleshooting requirements and other things;
> syslog does not have a standard content format because there are a
> wide number of vendors protecting their space, and the demand for
> backwards compatibility to all or most existing header formats has
> prevented progress in the syslog (security) WG. Faced with
> requirements comparable to those faced by the older protocols during
> their design, I expect netconf would fail to assimilate them properly.
> Therefore, if the purpose of netconf is to be a general purpose NM
> protocol, we need to have a serious discussion about the requirements
> that must be met to achieve successful assimilation.
> 
> I find the existing proposal has plans to assimilate other protocols -
> "The purpose of this [syslog-to-netconf] mapping is to provide an
> unambiguous mapping to enable consistent multi-protocol
> implementations as well as to enable future migration." and to attempt
> to standardize that which the syslog community has failed to
> standardize - "The intent is to promote the use of the NETCONF
> interface and not to simply provide a wrapper and additional delivery
> mechanism for syslog messages.  NETCONF events are intended to be well
> defined and structured, therefore providing an advantage over the
> unstructured and often times arbitrarily defined syslog messages (i.e.
> the message field)."
> 
> I am a strong supporter of judicious reuse of NM and security
> solutions across NM interfaces, but I believe apparent convergence
> opportunities need to be discussed and for  each convergence we need
> to consider the requirements met by each protocol and whether a
> converged solution continues to meet those requirements or
> deliberately does not meet some requirements.
> 
> I am bothered by the fact that netconf, a configuration protocol, is
> being redesigned in the current proposal to carry syslog messages that
> may have nothing to do with configuration, and it is expected that
> even more stuff, also possibly not related to configuration, will be
> carried in a new event message format. Operators at the IAB Network
> Management Workshop apparently did not find syslog sufficiently broken
> to request that a new event messaging capability be designed, so I
> have concerns that the current proposal includes a brand-new
> notification solution.
> 
> If netconf will become the new general purpose mgmt protocol for the
> IETF, we should do this deliberately, not as a side-effect of adding a
> notification operation to netconf.
> 
> David Harrington
> FutureWei Technologies, a Huawei company
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org 
> > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
> (Dan)
> > Sent: Monday, March 27, 2006 5:20 AM
> > To: Andy Bierman
> > Cc: Netconf (E-mail)
> > Subject: RE: Interim attendance survey
> > 
> > [...] I am aware that this good shape is
> > apparent, and there is little agreement on the problem space, and
> too
> > little review of the draft that includes a proposed solution even to
> > determine the level of agreement. I would encourage the WG to focus
> on
> > discussing the problem space (why are we doing notifications?) and
> the
> > draft and other options for solutions more intensively on the 
> > list. Let
> > us see in the next couple of weeks if we can reach more convergence
> on
> > the 'why' and 'how' questions. 
> > 
> > If we do have contributions about the scope and reviews of 
> > the draft and
> > solutions on the list we have a chance to better converge and reach
> > agreement. If the level of apathy stays the same, I am not sure that
> a
> > partially attended interim meeting would help. 
> > 
> 
> 
> 
> 
> 
> --
> 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/>