RE: Netconf over SOAP

["Mi-Jung Choi" <mjchoi@postech.ac.kr>]

On Thursday, October 23, 2003, at 05:04 AM, Mi-Jung Choi wrote:
>> We would like to add a few more points to the previous I-D of Netconf

>> over SOAP.
>> 1. We proposed that the agent embedded HTTP client as well as HTTP 
>> server
>>  for asynchronous notification. The previous draft suggested the use 
>> of SOAP
>> over BEEP or polling mechanism as the solutions of asynchronous 
>> notification.

> This mechanism for notifications over HTTP has been discussed, but
> was not included in the current draft due to the complexity of
> initiating the reverse connection from the agent.  
> What is your proposal?

=> What complexity? Perhaps can you give us some details?
If the agent has the HTTP client, the agent can easily connect to the
HTTP server in the manager. 
The agent can send an asynchronous notification message to the manager
through the HTTP client.

>> 2. We suggested the use of XPath for selection of partial 
>> configuration data
>>   instead of using sub-tree filtering. So the use of XPath does not 
>> need to insert
>>   operation attributes(merge, replace, and delete) between the 
>> configuration data.
>>   This shows a clear boundary between the configuration and operation
>>   in the <edit-cofig> operation.

> This would not be specific to NETCONF over SOAP, but XPath mechanisms
> are of interest for NETCONF.

>> 3. We redesigned the <edit-config> operation in order to use XPath.
>>   Without the three attributes such as "merge", "replace" and
"delete",
>>   the <edit-config> operation is transferred into the 
>> <edit-config-merge>, <edit-config-replace>
>>   and <edit-config-delete> operations. The manager can directly call 
>> these operations from
>>   the agent.

> There are concerns that making XPath mandatory may be too heavy
> for some devices, but any implementation experiences are welcome.
=> We simply recommend the use of XPath for the selection of 
parts of XML data.  
In practice, the XML-based agent must need its own XML parser.
And the use of XPath may require heavier XML parser.
We tested several exiting XML Parsers and chose the lightest one to work
on. 

We are currently working on optimizing the source code.

>> 4. We mentioned the <rpc> element was unnecessary in the SOAP RPC 
>> message
>>   because the use of <rpc> prevented the manager from directly
calling 
>> base operations.
>>   We hope that the NETCONF protocol provides more flexibility to the 
>> NETCONF operation message
>>   considering a RPC mechanism.

> <rpc> is specific to NETCONF and was retained with SOAP so that
> application code could be easily shared between BEEP, SOAP, and SSH
> implementations.  It's true that the use of the <rpc> tag affects
> source code, but its cosmetic:

> agent.rpc(GetConfig g);
>   vs
> agent.getConfig();

=> The advantage of SOAP over BEEP and SSH is to use RPC mechanism. 
But the use of <rpc> tag prevented the manager from directly calling
base operations 
such as <get-config>, <edit-config> and etc.  So the advantage of SOAP
RPC 
disappears and the use of SOAP may cause overhead.

SOAP implementation automatically encodes SOAP RPC message by calling
RPC operations.
Developers using SOAP environment do not need to implement the message
encoding portion 
unlike BEEP and SSH. But they must know the parameters and return values
of RPC operations.

So, we mentioned the use of WSDL as the description of RPC operations
for using RPC mechanism.  
To improve interoperability, the parameters of RPC operations must be
defined 
in NETCONF over SOAP. 

The SOAP RPC message parsing is supported by the SOAP implementation.
The parameter parsing of RPC operations is merely needed in NETCONF over
SOAP.
But developers using BEEP and SSH need to parse a full message including
<rpc> tag of a NETCONF protocol.

Thanks.
/Mi-Jung Choi





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