[resend] OT: operators script writers' experience wanted

Eliot Lear lear at cisco.com
Wed Sep 10 15:01:13 UTC 2003


[For some reason, the first message ended up in the bit bucket]

Dear all,

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
in expect(1).

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,

Eliot







More information about the NANOG mailing list