RE: NETCONF over TLS

["David B Harrington" <dbharrington@comcast.net>]

Hi,

In the Syslog WG, we debated having a TLS transport draft, since we
already had a syslog over BEEP RFC. The WG is primarily made up of
implementers, and they found very little demand for BEEP from
operators.

Many already know I favor a common secure transport layer for multiple
NM protocols. I think the concept of BEEP is wonderful, since it
**standardizes** secure transport for NM, providing a more secure
environment across NM interfaces, and reducing security configuration
work. But operators seem to refuse to use it, either because the
toolkits that have been available were not good enough, or the
deployment introduces more problems than it solves. 

I do not know how to convince operators to adopt BEEP. I think the
best approach will be to make it available in widely-used products,
and get operators to try out a good solid implementation with solid
support. I believe BEEP is now being shipped in Cisco products, and
new BEEP toolkit implementations are becoming available, so maybe that
will help turn the tide on BEEP deployment.

Until BEEP is accepted by operators, I do not believe we should
disallow a Netconf/TLS transport just because there is a Netconf/BEEP
transport. If BEEP is accepted by operators because it reduces the
work of deploying security for multiple NM protocols, the TLS
transport might just go away.

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net] 
> Sent: Tuesday, June 19, 2007 10:42 AM
> To: Eliot Lear
> Cc: David B Harrington; 'Andy Bierman'; 'Netconf (E-mail)'
> Subject: Re: NETCONF over TLS 
> 
> Eliot Lear writes:
> >This is where BEEP does its thing.  You do both TLS *and* SASL, and

> >voila: you can mix and match, even, based on deployment needs.
> 
> Can we hear from folks with experience with netconf/beep?  I was
> an early advocate for beep, but our experience was fairly negative.
> 
> For us, the quality of the freely-available implementations, as
> well as issues with the spec, were seen as trouble, but the bigger
> issue was just the complexity.  Yes, you can read a (decoded) beep
> session, but do developers understand what they are looking at
> without smoke pouring from their ears?
> 
> Thanks,
>  Phil
> 



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