RE: NetConf should fully exploit BEEP's rich features

[Andy Bierman <abierman@cisco.com>]

At 06:51 AM 9/26/2003, Eamon O'Tuathail wrote:
>Eliot,

I think you missed an important point that Eliot made in
a previous email.  We want to be as transport-independent
as possible.  We want to be able to modularize an 
implementation so that the protocol message handling code
will continue to work, even if the underlying transport
protocol changes.  Maintaining a consistent XML syntax
across different transports is required to achieve this goal.

Andy


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


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