Re: Is beep really what operators would want?

[Kevin C Miller <kevinm@andrew.cmu.edu>]

>   Specifically, I'm not sure
> that anyone could use the protocol without some minimal set of tools
> (I'm sure a perl module would be easy to write for helping with the
> communication requirements, of one doesn't exist yet).
I agree that BEEP would seem to exclude the cut-n-paste method of using 
xmlconf.

>   Maybe the
> simple-to-use-over-telnet type protocol requirement is obsolete?
If xmlconf is merely complimentary to a "human" CLI, then I see no 
requirement for a simple-to-use-over-telnet interaction requirement. 
However, I would guess that if (because?) it's easier/cheaper/a better 
value to implement xmlconf, new products will start to lack the human CLI. 
This would be unfortunate, as it would be tempting to try and use the 
protocol interactively. With BEEP client tools, perhaps it would even be 
possible.

At the same time, I recognize the many different data and data models that 
might be considered for xmlconf inclusion: machine config, human config, 
monitoring, binary file transfer,  log data, accounting data, etc. The 
current draft includes machine config, monitoring, and log data. Of these, 
machine config is by far the most important to me, but I can see valid 
reasons for allowing all of these data types across the protocol. Perhaps 
it could be generic enough to support this? There are valid arguments why 
current protocols work for some of these solutions (machine config being 
the obvious sore thumb), though.

-Kevin

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