Re: Is beep really what operators would want?

[Phil Shafer <phil@juniper.net>]

"Little, Kevin C (IP)" writes:
>Maybe I'm wrong here; do really good NOC-jocks fly JUNOScript "by hand"?

Not by choice, no, but it's a very useful ability to have.

So when do folks type JUNOScript "by hand"? Here are the
scenarios I've seen:

- learning: cut-n-paste a snippet and see if what comes out
  is what you expected.
- debugging: from your debugger, print the string you are
  trying to send, cut-n-paste it into a raw connection, and
  see what's failing.
- PRing: cut-n-paste from your log file into email sent to
  support mailing lists.
- reproducing: I cut-n-paste from your email into my test
  box and see if I can reproduce your problem.

So folks see what they are sending (as a raw, cannot-be-misinterpreted
string) and can inspect it for obvious flaws. The interaction between
their XML snippet and the Junoscript server is simple and easily
debugged.  If something surprising happens, they can send this
snippet in an part of a support request.

The big win is delineating application problems from server problems.

So how does this fit into the netconf/BEEP world? I imagine a simple
front-end perl script that will do the BEEP/SASL connection startup
and begin accepting input when the management channel is opened.
Or (optionally) open the operations channel and start accepting
input for this channel. I then cut-n-paste my XML snippet, hit ^D
(or something), and the script takes my input, calculates the header,
logs the full RPC, sends the data to the server, and displays (and
logs) the response.

This script gives all the wins of cut-n-paste with minimal expense.

While I'm here, someone else made a comment about CLI.vs.XML.
XML isn't a replacement for a CLI. CLIs are designed to be used by
humans. An XML API is designed to be used by applications.  The
overlap of functionality may be large, but the overlap of format
is minimal. The trick is allowing the vendor to maximize overlap
in the code paths.

Also, the choice to ship a CLI with a product is mostly unrelated
to support for an XML API. It's more about the expectations of your
user base. A core router without a CLI would be as surprising as a
laser printer with one.

Thanks,
 Phil

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