-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com]
Sent: Tuesday, June 19, 2007 11:35 AM
To: David B Harrington
Cc: 'Phil Shafer'; 'Andy Bierman'; 'Netconf (E-mail)'
Subject: Re: NETCONF over TLS
Dave,
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.
Until recently operators didn't have a choice to even deploy
it, so I'd
not read too much into what operators think right just yet.
I understand the sentiment, and maybe we shouldn't put much stock in
what operators have done so far. However, I think operators did have a
choice of multiple syslog implementations that implemented
syslog/BEEP, and weren't sold by that solution. I don't understand why
they will be sold by Netconf/BEEP.
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.
But it's not just TLS- it's TLS + User level authentication +
framing.
Guys, that's what BEEP is.
If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL
+ framing? Where is the value-add for using BEEP instead of using the
independent components? How does BEEP make it easier for an operator
to operate their network than if they simply used TLS + SASL + a
standardized framing approach?
Eliot
--
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/>