|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical [resend] OT: operators script writers' experience wanted
[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
|