[For some reason, the first message ended up in the bit bucket]
Over the last few years, a bunch of us from the vendor community have
sought your opinion about doing programmatic configuration to routers,
switches, and the like. Over the last few months, the NETCONF working
group was formed in the IETF. This working group started with a draft
that uses BEEP as a transport. We heard from you that you want an SSH
and for that matter a serial interface to the protocol. Our goal is to meet operator needs while at the same time providing sufficient formalism that scripts won't break so easily.
In the latest iteration of the draft we've split the NETCONF protocol
from the transport mapping and defined several transport protocol
mappings, including SSH.
I'd like to raise with you some concerns the working group has had with
SSH, and gather your opinions about how to proceed.
As implementors we're very concerned about prompts and asynchronous
messages. To address this, we plan to implement the transport mapping
through the subsystem facility, so that you don't get MOTDs, and you
don't get prompts or other stuff that make scripts go crazy. It's all
that other stuff that you script writers end up having to special case
Several of the working group members have extensive SSH experience,
however. They have expressed concerns regarding the applications used, and in particular OpenSSH. Specifically, the concern is about whether people would end up having to use expect(1) with an SSH application due to messages the local program generates. We are in particular not talking about messages generated by the remote end (e.g, the router) but the SSH program itself.
Question number 1: does this behavior present current script writers
problems? How have you gotten around this? Is it not an issue?
The other issue we have is that we wonder whether what is really wanted
is a way to prototype on the TTY, while still being able to use a more
formal interface once things are debugged. If the idea is to be able to
cut and paste "netconf" stuff into the TTY, this doesn't mandate a
formal protocol definition. Vendors can just "do it".
On the other hand, question # 2 if that leaves the one protocol as NETCONF over BEEP with an informal way to get to NETCONF over SSH, does that present operators problems? For instance, are you relying on SSH public/private user keys as your authentication mechanism? BEEP uses TLS and at least server-side certificates (TLS is nearly identical to SSL).
For TTY access, is it sufficient that the protocol be usable on the TTY for cut and paste purposes? This would be the equivalent of /usr/sbin/sendmail -bs or typing "xml" at the command prompt.
If you could respond to me, I'll be happy to summarize.
Thanks for your comments,