Subject: Re: every message only can have one operation?

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2006 07:02:04 -0800

王罕 wrote:

>  thanks Andy, but why can't we put more methods in a rpc message?
>it can reduce the Network management messages on Internet, can't it?
>  
>
(I cc;ed the WG because this issue keeps coming up)

It adds a lot of complexity to the protocol to do this.
Since configuration is a relatively rare activity, it doesn't really
save much bandwidth anyway.  We aren't very worried
about congestion due to network configuration PDUs.

(In your example, you saved about 1% -- that's all.
Once you add some overhead to differentiate the multiple replies,
you give that savings back, and then some.)

>  
>
>>no -- only 1 RPC method per <rpc> request is allowed
>>
>>Andy
>>
>>    
>>
>
>  
>

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2006 08:06:11 -0800

> you give that savings back, and then some.)

BTW, this is obviously a solved problem in other formats.
The correct way to do what you want could be added as
a vendor extension. For example:

  <batch xmlns="vendor-ns" group="101" label="bgp-upgrade-jan06">    
     <rpc message-id="101" xmlns="netconf-ns">
        <lock> .... </lock>
     </rpc>
     <rpc message-id="102" xmlns="netconf-ns">
        <get-config> .... </get-config>
     </rpc>
     <rpc message-id="103" xmlns="netconf-ns">
        <copy-config> .... </copy-config>
     </rpc>
     <rpc message-id="104" xmlns="netconf-ns">
        <unlock> .... </unlock>
     </rpc>
  </batch>

We want to keep the protocol simple to start out.
Less complexity, less code, more chance vendors will get it right.

Andy