|
Hello all, We would like to add a few
more points to the previous I-D of Netconf over SOAP.
Here are some issues to consider : 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. 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. 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. 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. 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. 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. And if necessary, we’d
like to submit our version of I-D. Thanks, Mi-Jung Choi |