RE: Netconf over SOAP

["Chen, Weijing" <Weijing_Chen@labs.sbc.com>]

Mi-Jung,

Have you posted your draft yet?  I would like to have a complete picture to
understand more.  Sometime without a draft to present your view, other
people might treat your view not too serious.




--

Weijing Chen



> -----Original Message-----
> From: Mi-Jung Choi [mailto:mjchoi@postech.ac.kr]
> Sent: Tuesday, October 28, 2003 2:47 AM
> To: 'Ted Goddard'; netconf@ops.ietf.org
> Subject: RE: Netconf over SOAP
> 
> 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/>

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