Why are we doing netconf?

[David Harrington <dharrington@huawei.com>]

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