RE: NetConf should fully exploit BEEP's rich features

["Eamon O'Tuathail" <eamon.otuathail@clipcode.com>]

Eliot,

NetConf should exploit the functionality of the underlying bindings as much
as possible - but if a new NetConf-specific RPC layer is really needed, then
that is fine by me. <RPC> adds a little complexity (not very much,
admittedly) so I am just wondering aloud if we can get by without it. 

The <RPC-PROGRESS> message would strike me as an ideal fit for a BEEP ANS
message on the operations channel (as opposed to the current BEEP RPY
message on the management channel). 

The <RPC-ABORT> message is more complex - as it is sent on the management
channel by a sender who wishes to abort a RPC message he sent on the
operations channel. Here NetConf does need to define a new message - and as
parameters it needs to be able to identify the operations message to abort.
At the moment, NetConf RPC defines its own message-id field - could this
task be given to the underlying binding? BEEP can identify any message by
BEEP channel id/BEEP message id combination, and some of the WS_xxx
standards being defined above SOAP will allow for message identification
also. 

The <RPC-ERROR> message fits fine inside a BEEP RPY message, as you have
already defined. 

Both BEEP and SOAP offer rich messaging constructs - SSH does not. So maybe
my main question is how much should we expect the underlying binding to be
"smart"? The smarter it is, then the simpler NetConf becomes, and hence it
is much more likely to be implemented and widely deployed.  This does put an
extra burden on bindings (e.g. SSH) that don't natively support rich
messaging constructs  - the binding will have to define these itself. 

> that the XML starts changing between transport bindings 

I don't believe you will get the exact same XML flowing over each binding.
The SOAP envelope consists of an XML wrapper, XML SOAP message headers, XML
soap message blocks - the BEEP message consists of a Mime-encoded blob. I do
believe you can handily get the exact same NetConf XML blob to flow inside a
SOAP message block and a BEEP message, but SOAP will have lots of wrapper
XML around its version and BEEP will have none. 

Eamon



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