Subject: [Syslog] Re: Why are we doing netconf? (fwd)

From: Chris Lonvick <[email-masked]>
Date: Wed, 29 Mar 2006 14:57:09 -0800 (PST)

Hi Folks,

I think that this resolves the netconf discussion.

Thanks,
Chris

---------- Forwarded message ----------
Date: Wed, 29 Mar 2006 14:53:20 -0800
From: Andy Bierman <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Cc: "Netconf (E-mail)" <[email-masked]>
Subject: Re: Why are we doing netconf?

Sharon Chisholm wrote:
>  hi

To all the people who want netconf to be a replacement
for syslog, snmp, ipfix, or whatever:

How about if we solve network configuration first,
then replace every other MGMT protocol in the world
with our new protocol?  (!)

I don't think the WG agrees that notifications in the
NETCONF protocol is a critical missing component,
let alone the most important critical missing component.

For NETCONF to be truly content-independent, the notification
delivery mechanism needs to be totally decoupled from
notification content.  There are a lot of different
ideas on this content, and who should standardize it.

I am totally opposed to the NETCONF WG working on syslog
content.  We need syslog experts (and the Chair) for that.
Sounds like a BOF in the works, but no NETCONF work item here.

I am also totally opposed to working on anything but
the bare minimum number of standard notifications
(like config-change) at this time.  You want a data model,
how about creating a writable interfaces table and an access control
model?  These are critical missing data models.

Andy

>
>  Thanks Dave for the well-thought through post.
>
>  I think the 'restriction' on Netconf for configuration has always been
>  an artificial one, but it has served us well. One of the big problems we
>  ran into with SNMP was we kept picking off the easier problem of
>  monitoring and never giving configuration enough focus. By limiting the
>  focusing primarily on configuration for Netconf 1.0, we have ended up
>  with a great technical solution that is seeing some good market uptake.
>
>  I think actual implementations of Netconf are not limiting themselves to
>  just configuration. The CLI never did. For deployments, the high cost of
>  having to integrate information from different sources gets weighed
>  against the cost of having to replace legacy systems. Sometimes it wins.
>  Sometimes it doesn't. For the most part, all this can be done using the
>  existing framework. The gaps that people run into when trying to do this
>  are, I believe, the same ones they run into while trying to use Netconf
>  for configuration - access control, data model and notifications.
>  Another gap might be 'operational' commands such as rebooting and
>  maintenance, but the universal requirements there are not yet clear to
>  me.
>
>  I've personally been working both the data modeling and the notification
>  issue. I'd work access control, but other then a sense that I'd like
>  something simpler then we've seen in the past, I have no idea what we
>  would need. They are all important, both for configuration-only
>  implementations and configuration-plus ones.  I've focused more on the
>  notification work lately because I was getting a lot of pushback on the
>  data model work from certain people, but I'm willing to put time on that
>  topic again. I think though, that for people looking to be able to pick
>  up third-party Netconf stacks, there are some big advantages to being
>  able to standardize on any extended protocol operations sooner rather
>  then later.
>
>  As far as whether if we said from day one that netconf would do more
>  than configuration and things would have been designed differently, I
>  don't now if that is the case. As far as being forced to solve problems
>  at some point in the future related to performance management if we
>  don't somehow engineer/re-engineer the protocol so it can't be used for
>  things like that, I don't think that would be helpful.   At that day in
>  the future the community can decide whether it wants to spend time on
>  that particular problem. Plus, unless at that point in the future we
>  learned that they were not also using Netconf for configuration, this
>  would be a sign of success.
>
>  So, in summary, I think the current notification work absolutely is
>  necessary for configuration management. I don't see the value of
>  precluding its use for other functions and I believe for the other
>  functions all we need to do is provide the ability to specify the
>  correct event class. I'm also willing to work on the other gaps.
>
>  Sharon
>
>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On
>  Behalf Of David Harrington
>  Sent: Tuesday, March 28, 2006 1: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/>
>
>
>  --
>  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/>
>
>

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