RE: Is beep really what operators would want?

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

"read and understand" is one thing. "write and invoke" is another.
Assuming appropriate logging such that the command flow can be made
visible to the operator, reading and understanding a captured exchange
between client and server is adequately addressed by XML, IMO. It is
textual, and can be deciphered by a human. The fact the BEEP header
might also be captured is of little consequence -- the human can pretty
much ignore it and concentrate on the meaty stuff between the <rpc> and
</rpc>.

But it is a different matter to manually create (from scratch or via
cut&paste) a valid, perfect-to-the-letter XML rpc invocation, plus the
BEEP header, and try and "play computer" with the other end of a live
RPC connection.

Several folks who've responded to this thread have convinced me that, in
dire situations, a "netconf XML/BEEP debugger" might be useful
("nxbdbg", anyone?:). But if that is not sufficient, and we need to come
up with a protocol that inherently and easily permits human operators to
become first-class participants, then *neither* BEEP *or* XML are good
choices.

My $.02...

Regards,
    -k  

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> Sent: Friday, June 20, 2003 3:36 PM
> To: wjhns1@hardakers.net
> Cc: netconf@ops.ietf.org
> Subject: Re: Is beep really what operators would want?
> 
> >>>>> Wes Hardaker writes:
> 
> Wes> My real question was: are all the operators happy with the above
> Wes> notion of connecting to a device (IE, you must have a front end
> Wes> connection program which is *not* telnet or ssh) in order to do
> Wes> your minimal cut-n-paste type examples.  I'd argue for "yes" its
> Wes> sufficient but I wasn't sure everyone else agreed with myself or
> Wes> the protocol designers and was looking for other opinions.
> 
> In good old SNMP days, there were several SNMP extensions for various
> well known scripting languages with the idea that people do not have
> to know human unfriendly things such BER encodings or OIDs. Still,
> operators told us that they do not trust these tools and want to be
> able to read and understand the messages if things do not work as
> expected.
> 
> /js


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