RE: Is beep really what operators would want?

["Little, Kevin C (IP)" <kclittle@enterasys.com>]

> -----Original Message-----
> From: Wes Hardaker [mailto:wjhns1@hardakers.net]
> Sent: Thursday, June 19, 2003 1:48 PM
> To: Phil Shafer
> Cc: Little, Kevin C (IP); netconf@ops.ietf.org
> Subject: Re: Is beep really what operators would want?
> 
> >>>>> On Thu, 19 Jun 2003 03:16:16 -0400, Phil Shafer
<phil@juniper.net>
> said:
> 
> Phil,
> 
> Fantastic summary.  Thanks!
> 
> Phil> So how does this fit into the netconf/BEEP world? I imagine a
simple
> Phil> front-end perl script that will do the BEEP/SASL connection
startup
> Phil> and begin accepting input when the management channel is opened.
> Phil> Or (optionally) open the operations channel and start accepting
> Phil> input for this channel. I then cut-n-paste my XML snippet, hit
^D
> Phil> (or something), and the script takes my input, calculates the
> header,
> Phil> logs the full RPC, sends the data to the server, and displays
(and
> Phil> logs) the response.
> 
> That was exactly what I was trying to get at, but stated much more
> clearly and with better examples.  My real question was: are all the
> operators happy with the above notion of connecting to a device (IE,
> you must have a front end connection program which is *not* telnet or
> ssh) in order to do your minimal cut-n-paste type examples.  I'd argue
> for "yes" its sufficient but I wasn't sure everyone else agreed with
> myself or the protocol designers and was looking for other opinions.
> 

Agreed, good summary!

As this approach does not impose any new requirements on netconf, I can
buy it. But, I'm not so sure it will be that simple an applet. Will it
have to do something intelligent with the capabilities exchange? Should
it validate the XML snippet that's been pasted? Or at least check for
well-formedness? (You and I both know the operator is often going to
change "just one little thing" in the middle of the XML before pasting
it back!) If available, shouldn't it read the notification channel?
Etc., etc.

But maybe this is getting off-topic for netconf. Just thought I'd point
out a slippery slope (I seem to find and fall off them quite easily...)

       -k


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