Re: Netconf over SOAP

[Ted Goddard <ted.goddard@windriver.com>]

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
> overBEEP 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?

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

> 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();

> 5. We defined WSDL for RPC operation descriptions including parameters 
> of RPC operations,
>   data types of parameters, and return values of RPC operations.
>   WSDL of RPC operations is very important in the NETCONF 
> implementation using RPC mechanism.
>   So we hope the definition of WSDL of RPC operation become a standard 
> like a NETCONF protocol
>   message.  Appendix (A) shows the examples of our WSDL. 

Please feel free to post your WSDL for discussion.

> 6. We suggested a slightly modified mechanism for creating session by 
> adding the <create-session>
>   operation and the context of Session-ID. The use of <create-session> 
> relieves the overhead of
>   agent message parsing.

The current scheme of using HTTP headers involves minimal parsing ... 
however
suggestions for other mechanisms are welcome.

> And if necessary, we’d like to submit our version of I-D.

The best way to proceed is by discussing the specific issues on
this list.

Thanks,
Ted.


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