Subject: [Syslog] FW: Why are we doing netconf?

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 29 Mar 2006 09:14:17 +0200

WG,

this is another posting from the NETCONF WG which I also consider quite
important for the syslog WG.

Rainer 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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
> [email-masked] 
> [email-masked]
> [email-masked]
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 29 Mar 2006 05:19:39 -0800 (PST)

Hi Folks,

This has been a debate in the netconf WG for some time.  I've had talks 
with many of the people participating in netconf over the past few years. 
I've been urging them to use syslog-protocol if they decide to pursue 
notifications within netconf.  At various past IETF meetings I've usually 
gotten people to agree to that.  And at other IETF meetings, and on their 
mailing list, the question continues to resurface and they have to address 
it again.

For those who are interested in the discussion but who are not subscribed 
to both WG mailing lists, please visit the netconf archive:
   https://ops.ietf.org/lists/netconf/

Thanks,
Chris