Subject: Re: Why are we doing netconf?

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 29 Mar 2006 12:18:36 +0200

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

--
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: "Rainer Gerhards" <[email-masked]>
Date: Wed, 29 Mar 2006 16:15:54 +0200

Sharon, 

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 29 Mar 2006 18:10:58 +0200

This may be a good list to start a discussion about Netconf
notifications, but are all these requirements at the same level of
priority? Maybe there is a sub-class of higher priority requirements
that can be met with a simpler protocol? 

Dan

> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Wednesday, March 29, 2006 5:09 PM
> To: [email-masked]
> Subject: RE: Why are we doing netconf?
> 
> 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
> 
> 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>
> > benefitial. </Rainer>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 29 Mar 2006 18:15:06 +0200

Maybe this is part of the discussion suggested by Dave Harrington about
'a strategic vision about converging aspects of the various NM protocols
and NM security solutions' discussion that needs to be conducted by the
management and security communities altogether. 

Dan

> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Wednesday, March 29, 2006 4:16 PM
> To: Sharon Chisholm; [email-masked]
> > 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.

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 29 Mar 2006 18:20:15 +0200

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

I sympathize with this kind of approach, but we also need to recognize
that this type of approach is ambitious, and speaks about a longer term
vision, which may take time to start and complete. I am reluctant to
declare a stop in all new protocol design and applicability statements
for existing protocol in management while waiting for that vision to
happen. I would say let us start preparing the strategic vision
discussion with at least a I-D to be discussed at the O&M Area Meeting
in Montreal. At the same time let us continue existing work that has
enough consensus and warm bodies to push for it - this will provide us
solutions in more contained spaces that will play as pieces in the
puzzle of the 'vision'. 

Dan

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 29 Mar 2006 20:56:57 +0200

I was not necessarily pleading in favor or against a specific protocol,
but rather making the case that back in 2002 and even more today there
may be room for looking for a consistent security framework, that brings
together different protocols each better suited for specific management
functions rather than design one protocol to perform all management
operations.

Dan

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Wednesday, March 29, 2006 7:57 PM
> To: Romascanu, Dan (Dan)
> Cc: Sharon Chisholm; Netconf (E-mail)
> Subject: Re: Why are we doing netconf?
> 
> Hi Dan,
> 
> > It also was intended to meet the needs of the operators as 
> they were 
> > scanned by 2001-2002. They told us then that they can leave 
> well with 
> > the alarms and performance monitoring mechanisms in SNMP, 
> but consider 
> > configuration by SNMP a dead horse.
> >   
> 
> Actually, for fault management management and alarms some 
> consider SNMP a dead horse.  Most enterprises in particular 
> prefer SYSLOG and ASCII. 
> SPs say they like SNMP but then they use tools like 
> Netcool/CIC, and so SYSLOG does very well for them as well.  
> In the end I think we'd find agreement between the two groups 
> that standardized events should tail differentiation.
> 
> I also think one of the reasons they considered SNMP a dead 
> horse was lousy integration with their existing AAA.  ISMS 
> may help this.
> 
> Eliot
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 30 Mar 2006 09:11:10 -0500

<Juergen>
> Well, there are people who will be evaluating existing solutions 
> against these requirements, so I'd prefer to have it in there with a 
> note that in Netconf this is part of the content layer, not the 
> protocol operations. We will need to have a sense of *how* predictable

> content comes into being, even if it is does in the data model.

So are you saying you want to have a requirement which says:

* solution should leave the definition of notification formats 
  to the data models

I am not really sure I captured the idea here...

</Juergen>

More like

* solutions should provide the ability to specify the content of
notifications to ensure predictability. This can be done via a data
model definition.

Sharon