beep, soap, ssh, the world, and everything

[Eliot Lear <lear@cisco.com>]

I wish I could have attended Vienna, but the timing was just bad.  I'd 
like to provide my view on two points that were discussed at the WG meeting.

First, I'd like to reiterate my position that you need to have at least 
one mandatory transport mapping.  Without at least one mandatory mapping 
it is possible that one developer will implement one mapping and another 
will implement a different one, and the two will not interoperate. 
Having a minimal level of interoperability is a good thing.  We largely 
have it today in the forms of telnet and ssh.

This is not to say that there can be only one mapping.  Indeed we might 
want to mandate more than one mapping, for all I know.

Second, my understanding is that if there were to be only one, people 
were leaning towards SSH.  I prefer BEEP.  Rather than debate the point, 
I'd like to discuss requirements for a moment.

1.  As a matter of requirements we find it useful to extend the 
traditional management model such that the agent connects to the manager 
instead of the other way around.  This is beneficial to the manager in 
as much as the manager needn't continually attempt to connect to a 
device that is intermittantly connected, or where other than 
configuration management is required.

It is also beneficial to turn the connection around in order to be able 
to transit firewalls and NATs, some of which may not be in the same 
administrative domain.

2.  Any mechanism that uses character processing is inefficient from a 
non-interactive point of view.  We are debating a configuration 
protocol, which by its nature is non-interactive.  We should take this 
into account in a protocol decision.

3.  Whatever protocol we choose it should not be possible for spurious 
irrelevant messages that our beyond the bounds of the protocol to be 
sent.  This includes banners, usernmame/password prompts, configurable 
host prompts, and (God help us) unsolicited messages such as SYSLOG 
messages configured on a VTY.  All of these things can break 
configuration mechanisms.

4.  Whatever protocol we choose should utilize standard authentication 
mechanisms and should tie into common EXISTING authentication 
infrastructures.  Similarly, the protocol should provide for 
confidentiality.

5.  Authorization needn't be addressed at the transport mapping level in 
ways other than "Permission Denied".  I will assert this until someone 
can demonstrate a common counterpoint.

While multi-channel support is nice, it's not entirely necessary.  While 
it would be nice to leverage existing tools, we should only do so if the 
those tools address the above issues.

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